When the OAuth callback returns to our app, we need to ensure that this is the end of a valid authentication sequence that we initiated, and not a forged redirect.
This action ensures that the user is authenticated and their token is valid.
This action ensures that the user is authenticated and their token is valid. Is a user is not logged in or their token has expired then they will be authenticated.
The AuthenticatedRequest will always have an identity.
The configuration class for Google authentication
The Directory API can tell you what groups (ie Google Group) a user is in.
The Directory API can tell you what groups (ie Google Group) a user is in.
You can use a Service Account to access the Directory API (in fact, non-Service access, ie web-user, doesn't seem to work?). The Service Account needs the following scope: https://www.googleapis.com/auth/admin.directory.group.readonly
You also need a separate domain user account (eg [email protected]), which will be 'impersonated' when making the calls.
A Service Account calls Google APIs on behalf of your application instead of an end-user.
A Service Account calls Google APIs on behalf of your application instead of an end-user. https://developers.google.com/identity/protocols/OAuth2#serviceaccount
You can create a service account in the Google Developers Console:
https://developers.google.com/identity/protocols/OAuth2ServiceAccount#creatinganaccount
email address of the Service Account
the Service Account's private key - from the P12 file generated when the Service Account was created
the email address of the user the application will be impersonating
When the OAuth callback returns to our app, we need to ensure that this is the end of a valid authentication sequence that we initiated, and not a forged redirect. Rather than use a nonce, we use a signed session id in a short-lifetime Json Web Token, allowing us to cope better with concurrent authentication requests from the same browser session.
"One good choice for a state token is a string of 30 or so characters constructed using a high-quality random-number generator. Another is a hash generated by signing some of your session state variables with a key that is kept secret on your back-end." - https://developers.google.com/identity/protocols/OpenIDConnect#createxsrftoken
The design here is partially based on a IETF draft for "Encoding claims in the OAuth 2 state parameter ...": https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state-01