https://github.com/lithdew/oauth2-go

What does it take to write a minimal security-first OAuth 2.0 Server w/ OpenID Connect support in Go?
https://github.com/lithdew/oauth2-go

go oauth2-server openid-connect

Last synced: about 12 hours ago
JSON representation

What does it take to write a minimal security-first OAuth 2.0 Server w/ OpenID Connect support in Go?

• Host: GitHub
• URL: https://github.com/lithdew/oauth2-go
• Owner: lithdew
• Created: 2021-05-30T10:11:42.000Z (over 3 years ago)
• Default Branch: master
• Last Pushed: 2021-06-04T15:15:28.000Z (over 3 years ago)
• Last Synced: 2024-11-14T00:34:08.825Z (29 days ago)
• Topics: go, oauth2-server, openid-connect
• Language: Go
• Homepage:
• Size: 45.9 KB
• Stars: 7
• Watchers: 3
• Forks: 2
• Open Issues: 0
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

• awesome-golang-repositories - oauth2-go - first OAuth 2.0 Server w/ OpenID Connect support in Go? (Repositories)

README

        
# oauth2

[IETF RFC 6749: OAuth 2.0](https://datatracker.ietf.org/doc/html/rfc6749)

## Security Considerations

1. [IETF RFC 6794 Section 1.4: Opaque access tokens](https://datatracker.ietf.org/doc/html/rfc6749#section-1.4)

2. [IETF RFC 6819 Section 5.1.4.1.3: No Cleartext Storage of Credentials](https://datatracker.ietf.org/doc/html/rfc6819#section-5.1.4.1.3)

3. [IETF RFC 6819 Section 5.1.4.1.4: Encryption of Credentials](https://datatracker.ietf.org/doc/html/rfc6819#section-5.1.4.1.4)

4. [IETF RFC 6819 Section 5.1.5.2: Determine Expiration Time](https://datatracker.ietf.org/doc/html/rfc6819#section-5.1.5.2)

5. [IETF RFC 6819 Section 5.1.5.3: Use Short Expiration Time](https://datatracker.ietf.org/doc/html/rfc6819#section-5.1.5.3)

6. [IETF RFC 6819 Section 5.1.5.8: Bind Token to Client id](https://datatracker.ietf.org/doc/html/rfc6819#section-5.1.5.8)

7. [IETF RFC 6819 Section 5.2.4.4: Binding of Authorization "code" to "client_id"](https://datatracker.ietf.org/doc/html/rfc6819#section-5.2.4.4)

8. [IETF RFC 6819 Section 5.2.4.5: Binding of Authorization "code" to "redirect_uri"](https://datatracker.ietf.org/doc/html/rfc6819#section-5.2.4.5)

9. [IETF RFC 7636: Proof Key for Code Exchange by OAuth Public Clients](https://datatracker.ietf.org/doc/html/rfc7636)

Authorization codes, and access tokens are generated by generating 32 bytes using a cryptographically-secure PRNG, and

passing it through HMAC-SHA256 with a secret key that is kept in the authorization server. The randomly-generated bytes

and MAC are then individually BASE64-URL-encoded with no padding, and concatenated together with a "." delimiter.

```

base64_url_no_padding(prng_bytes).base64_url_no_padding(hmac_sha256(prng_bytes, secret_key))

```

All OAuth 2.0 client secrets are bcrypt-hashed with a cost of 10. The server supports client credentials being passed

through either the HTTP `Authorization` header, or through the request body in the case the endpoint being queried

supports being queried with url-encoded form data as a request body.

OAuth 2.0 Implicit Flow and Resource Owner Password Credentials Flow are intentionally not going to be supported as they

are strongly advised against being used by recent IETF RFCs and several many identity providers.