auth
auth/doc.go
Let's test our verifyClient function. C'mon, it'll be fun! Add a function that tests the verifyClient function to our unit test suite. Basically, make sure that all the conceivable types of input have the right logic flow for what a "valid client" is. Also leave a note in client.go that makes it clear that public clients _should not be issued secrets in the first place_, because a public client that is issued a secret and specifies its client ID using the `client_id` POST body format will be told that it is not a valid client. While there are ways around this, the spec clearly states that non-confidential clients are not supposed to be issued secrets, so this seems like a nice way to conform to the spec or break trying.
| 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 |