OAuth

OAuth2

  • After a user logs in and grants your application access to their account, they will be redirected to your application's redirect URL which will contain an auth code. This auth code can then be used along with your client ID and client secret to establish an API connection.

  • Roles

    • Resource owner

    • Resource server

    • Client

      • Client must register itself with authorization server before initiating the protocol.
    • Authorization server

  • Authorization Grant

    An authorization grant is a credential representing the resource owner's authorization (to access its protected resources) used by the client to obtain an access token.

    • Types

      • Authorization code

        • Suitable for publicly available apps
        • Most secure grant type
        • If the client is a web app that has a server-side component, then you should implement the authorization code grant.
        • If you can use server-side scripting, then use this grant.
        • Workflow: OAuth 2.0: Authorization code grant flow (opens in a new tab)
      • Implicit

      • Resource owner password credentials

      • Client credentials

        • Suitable for private apps
        • Highly trusted applications, written by internal developers or developers with a trusted business relationship with the user.
        • All parties trust each other and no external resources are involved.
        • Usually used for machine-to-machine authorization.
        • Applications that need to access resources on their own behalf.
        • Workflow: OAuth 2.0 - Client credentials grant flow (opens in a new tab)
  • Access Token

    • Access tokens are credentials used to access protected resources.

    • Access Token Request

      • grant_type

        REQUIRED, Value MUST be set to authorization_code.

      • code

        REQUIRED, The authorization code received from the authorization server.

      • redirect_uri

        REQUIRED

        The redirect URIs are the endpoints to which the authorization server can send responses.

      • client_id

        REQUIRED, if the client is not authenticating with the authorization server as described in Section 3.2.1.

    • Access Token Scope (opens in a new tab)

      • A mechanism to define permissions for the access token in a fine-grained manner.

      • Typically a scope is mapped to one or multiple API methods of the service, but this is just a convention, so totally up to the internal design and implementation of the service.

    • Claims

      • aud

        The aud claim of an OpenID Connect ID Token defines which clients should accept it.

  • Refresh Token

    • Refresh tokens are credentials used to obtain access tokens.
    • This allows for a more seamless user experience, as the user will not need to re-authenticate every time the access token has expired.
    • Unlike access tokens, refresh tokens are intended for use only with authorization servers and are never sent to resource servers.
  • Resources

OpenID Connect (OIDC)

  • Authentication process is delegated to identity providers.

  • ID Token

    • The token to indicate a user has been authenticated

OpenID Connect Discovery

JavaScript Object Signing & Encryption (JOSE)

JSON Web Tokens (JWT)

  • A standardized container format to transfer claims between 2 parties, optionally validated and encrypted.

  • Header

    Identify which algorithm is used to generate the signature

    • Algorithm

      • RS256

        RS256 (RSA Signature with SHA-256) is an asymmetric algorithm, and it uses a public/private key pair: the identity provider has a private (secret) key used to generate the signature, and the consumer of the JWT gets a public key to validate the signature. Since the public key, as opposed to the private key, doesn’t need to be kept secured, most identity providers make it easily available for consumers to obtain and use (usually through a metadata URL).

      • HS256

        HS256 (HMAC with SHA-256), on the other hand, is a symmetric algorithm, with only one (secret) key that is shared between the two parties. Since the same key is used both to generate the signature and to validate it, care must be taken to ensure that the key is not compromised.

      • If you will be developing the application consuming the JWTs, you can safely use HS256, because you will have control on who uses the secret keys. If, on the other hand, you don’t have control over the client, or you have no way of securing a secret key, RS256 will be a better fit, since the consumer only needs to know the public (shared) key.

  • Payload

    A set of claims that are being transferred

  • Signature

  • Resources

JSON Web Signature (JWS)

JSON Web Key (JWK)

JSON Web Key Set (JWKS)

  • JWKS is a set of JWKs. The JSON object MUST have a keys member, which is an array of JWKs.

JSON Web Encryption (JWE)

  • Without JWE, the payload of JWT can be decoded and readable, therefore cannot be used to carry sensitive information.

  • With JWE, the encrypted JWT is suitable for secrets, such as OIDC ID Token or OAuth2 Access Token.

  • Resources

Spring Security OAuth2