OAuth/SSO | JWT (OAuth 2.0 Authorization Framework

… makes extensive use of HTTP redirections … [per] HTTP 302 status code, or any other method available via the user-agent …

Authorization, not authentication.
OpenID Connect (OIDC) deals with authentication.

Grant Types

• Authorization Code Grant (Request/Response)

  1. Front Channel (App to Authorization Server) Flow

     • Request Authorization Code

       curl -X GET -s \
           https://accounts.google.com/o/oauth2/auth?
               scope=gmail.insert gmail.send
               &redirect_uri=https://app.example.com/oauth2/callback
               &response_type=code
               &client_id=812741506391
               &state=af0ifjsldkj
       

       • Params (shown per line):
         • scope is, e.g., gmail.insert
         • redirect_url is that of the (HTTP 302) response header …
           • Location: <Send_Authorization_Grant_Here>
         • response_type code
         • client_id per prior registration with this Auth Server.
           • (Obtained per out-of-band process.)
         • state is a security flag; a'la CSRF (HTTP/1.1 302 Found Location: https://app.example.com/oauth2/callback? code=MsCeLvIaQm6bTrgtp7 &state=af0ifjsldkj
           • Params (shown per line):
             • code is the Authorization Code
             • state must match that at request, else reject the code!

       • Back Channel (Authorization Server to App API service) Flow

         • Request Authorization Token (using Authorization Code); Exchange

           POST /oauth2/v3/token HTTP/1.1
           Host: www.googleapis.com
           Content-Type: application/x-www-form-urlencoded
           
               code=MsCeLvIaQm6bTrgtp7
               &client_id=812741506391
               &client_secret={client_secret}
               &redirect_uri=https://app.example.com/oauth2/callback
               &grant_type=authorization_code
           

           • Params (shown per line):
             • client_id: app id
             • client_secret: app key
             • grant_type is Authorization Code Grant (type); OAuth has several Grant Types; is extensible/flexible.

         • Response

           {
             "access_token": "2YotnFZFEjr1zCsicMWpAA",
             "token_type": "Bearer",
             "expires_in": 3600,
             "refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA"
           }
           

           • … exchanging the Authorization Code (granted) for the Access Token. Thence make authorized requests …

             curl -I -X ${METHOD} -s \
                 -H "Authorization: Bearer ${_TOKEN}" \
                 http://${_RESOURCE_SERVER_ENDPOINT}
             
             # E.g., get email
             curl -X GET -s \
                 -H "Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA" \
                 https://www.googleapis.com/gmail/v1/users/1444587525/messages
             

• Resource Owner Credentials Grant

  • … suitable for clients (trusted first parties) capable of obtaining the resource owner's credentials (username and password, typically using an interactive form).
  • Also used to migrate existing clients using direct authentication schemes such as HTTP Basic or Digest authentication to OAuth by converting the stored credentials to an access token.

Golang OAuth Libraries

1. ORY Hydra [9K] | ory.sh/hydra
   • Server … OAuth 2.0 Server and OpenID Connect Provider optimized for low-latency, high throughput, and low resource consumption. … not an identity provider … _, but connects to your existing identity provider through a login and consent app.
2. OmniAuth: Standardized Multi-Provider Authentication [7K] | Wiki
   • Client … a black box that you can send your application's users into when you need authentication and then get information back.
   • Provider Strategies (@ Ruby)
3. OAuth2 for Go [3K] | GoDoc
   • Client … implementation for OAuth 2.0 spec.
4. Goth: Multi-Provider Authentication for Go [3K] | GoDoc
   • Client … lets you write OAuth, OAuth2, or any other protocol providers, as long as they implement the Provider and Session interfaces.

Identity Providers

• Amazon

• Google

• Scopes

  • … a mechanism in OAuth 2.0 to limit an application's access to a user's account. An application can request one or more scopes, this information is then presented to the user in the consent screen, and the access token issued to the application will be limited to the scopes granted.

• Grant Types

  • A Guide to OAuth2 Grants | OAuth2 Simplified | Understanding OAuth2
  • Use Authorization Code Grant type.
    • Redirect is to server-side handler, which appends its app creds (ClientID and secret) to user's authorization code recieved from Identity Provider, and sends that back to the Identity Provider to obtain an Access Token (JWT).
      • Not sure if this last bit is necessary; authorization code from Identity Provider may be all we need. Do we want/need actual access to user account at Identity Provider?

• Actors

  • Client:
    1. Public (Frontend app; javascript); can't be trusted with secret key.
    2. Confidential; (API server) can be trusted with secret key.
  • Resource Owner (RO): Owner and role of an app user; @ app frontend (browser).
  • Resource Server (RS): Our API server.
  • Authorization Server (AS): Identity Provider (Facebook, Twitter, Google, ...)

• [Tokens]

• What Is OAuth?

  • OAuth is a delegated authorization framework for REST/APIs. ... enables apps to obtain limited access (scopes) to a user’s data sans password. It decouples authentication from authorization …

• Using OAuth 2.0 to Access Google APIs

• Implementing OAuth 2.0 with Go

OpenID Connect (OIDC) 1.0

OIDC extends OAuth 2.0 … with a new signed id_token for the client and a UserInfo endpoint to fetch user attributes; is a simple identity layer on top of the OAuth 2.0 protocol. … a standard set of scopes and claims for identities.

Examples include: profile, email, address, and phone. … built-in registration, discovery, and metadata for dynamic federations. You can type in your email address, then it dynamically discovers your OIDC provider, dynamically downloads the metadata, dynamically know what certs it’s going to use, and allows BYOI (Bring Your Own Identity). It supports high assurance levels and key SAML use cases for enterprises.

Misc/Other/Older References

• Client ID and Secret
  • OAuth providers issue a client ID per application. The ClientID is public information, and is used to build login URLs, or included in Javascript source code on a page. The client secret must be kept confidential. If a deployed app cannot keep the secret confidential, such as single-page Javascript apps or native apps, then the secret is not used, and ideally the service shouldn't issue a secret to these types of apps in the first place._

URL sent to GitHub (OAuth Identity Provider) from our application

https://github.com/login/oauth/authorize?client_id=<APPs_GITHUB_OAUTH_ID>&redirect_uri=http://<APPs_DOMAIN>/oauth/redirect

Redirect URL is where we want Identity Provider (GitHub) to send this user upon SSO authentication per GitHub.

http://<APPs_DOMAIN>/oauth/redirect

After registering your app, you will receive a client ID and optionally a client secret. The client ID is considered public information, and is used to build login URLs, or included in Javascript source code on a page. The client secret must be kept confidential. If a deployed app cannot keep the secret confidential, such as single-page Javascript apps or native apps, then the secret is not used, and ideally the service shouldn't issue a secret to these types of apps in the first place.