auth
auth/doc.go
Make client use our auth(n/z) scheme. Our auth(n/z) scheme can be loosely defined as "encrypted tokens that nginx transforms into headers" and "scopes for bypassing ACL". Our Go client, which is what we'll be using to have services communicate with each other, follows this paradigm now by auto-injecting the headers we'll need to identify ourselves. This will work behind our firewall, but will be useless for the rest of the world, which will need to go through the nginx bastion that can strip the headers and replace them with the headers appropriate to the token attached to the request. This did involve setting a static client ID as the client for our email_verification listener. Ideally, this would cause Client registration (using that ID) when the listener starts up, ignoring ErrClientAlreadyExists. I don't want to have to write the code that will allow us to bypass the Client ACL properly right now, though, so we're just going to have to remember to manually create that Client. Or not. I don't think it will do any harm (outside the OAuth flow) to be using a Client ID that doesn't actually point to a Client. I just think it'd be good for record-keeping purposes.
| 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@158 | 6 are permitted to login using any email address they have on record. Care is also taken to be able |
| paddy@158 | 7 to mitigate attacks that have already happened and plan ahead for the worst case scenarios. |
| paddy@57 | 8 |
| paddy@57 | 9 An OAuth2 provider is also built-in and provided, complete with client registration and management, |
| paddy@57 | 10 as well as a specification-based set of handlers for managing the issuing of grants and tokens. Token |
| paddy@57 | 11 validiity may be asserted through an API, or a proxy service is provided for stripping auth-specific |
| paddy@57 | 12 information from requests and replacing it with a trusted header containing information about the user |
| paddy@57 | 13 and client that authorized the request. |
| paddy@57 | 14 */ |
| paddy@57 | 15 package auth |