auth
auth/doc.go
Refactor verifyClient, implement refresh tokens. Refactor verifyClient into verifyClient and getClientAuth. We moved verifyClient out of each of the GrantType's validation functions and into the access token endpoint, where it will be called before the GrantType's validation function. Yay, less code repetition. And seeing as we always want to verify the client, that seems like a good way to prevent things like 118a69954621 from happening. This did, however, force us to add an AllowsPublic property to the GrantType, so the token endpoint knows whether or not a public Client is valid for any given GrantType. We also implemented the refresh token grant type, which required adding ClientID and RefreshRevoked as properties on the Token type. We need ClientID because we need to constrain refresh tokens to the client that issued them. We also should probably keep track of which tokens belong to which clients, just as a general rule of thumb. RefreshRevoked had to be created, next to Revoked, because the AccessToken could be revoked and the RefreshToken still valid, or vice versa. Notably, when you issue a new refresh token, the old one is revoked, but the access token is still valid. It remains to be seen whether this is a good way to track things or not. The number of duplicated properties lead me to believe our type is not a great representation of the underlying concepts.
| paddy@57 | 1 /* |
| paddy@57 | 2 Package auth provides an authentication service for managing user accounts and an OAuth2 provider. |
| paddy@57 | 3 |
| paddy@57 | 4 The service is an opinionated implementation of authentication using passphrases and the |
| paddy@57 | 5 code.secondbit.org/pass package to implement user credentials and accounts. Additionally, users |
| paddy@57 | 6 are permitted to login using their email address on record or their username interchangeably. |
| paddy@57 | 7 Care is also taken to be able to mitigate attacks that have already happened and plan ahead for |
| paddy@57 | 8 the worst case scenarios. |
| paddy@57 | 9 |
| paddy@57 | 10 An OAuth2 provider is also built-in and provided, complete with client registration and management, |
| paddy@57 | 11 as well as a specification-based set of handlers for managing the issuing of grants and tokens. Token |
| paddy@57 | 12 validiity may be asserted through an API, or a proxy service is provided for stripping auth-specific |
| paddy@57 | 13 information from requests and replacing it with a trusted header containing information about the user |
| paddy@57 | 14 and client that authorized the request. |
| paddy@57 | 15 */ |
| paddy@57 | 16 package auth |