OAuth2 authorizatation that enables applications to obtain limited access to user accounts on HTTP service. it works by delegating user authentication to the service that hosts the user account and authorizing third-party applications to access the user account.

it provides a flow for web applications, desktop applications, mobile phones, and living room devices.

key concepts of OAUTH 2.0 include:

Resource owner: the end user who owns the data and grant access to their resources.

client: the application requesting the access to resources on behalf of the resource owner

authorization Server: the server that authenticates the resources, it can accept or respond to protected resources requests using access tokens.

OAuth2 defines four main grant types for different use cases:

1. Authorization Code: Used by web and mobile applications, where the client redirects the user to an authorization server, obtains an authorization code, and exchanges it for an access token.

   1. public grant works by adding an extra layer of security to the standard Authorization Code flow, making it more suitable for public clients like mobile and single-page applications.

   2. the main difference between this normal and the public is at the step of getting the token, where the normal will include the client ID and client secret, but the public will include the code-verifier that was used to generate the code-challenge at the first request.

2. Implicit: Designed for clients implemented in a browser using a scripting language, this grant type obtains an access token directly without an intermediate authorization code step.

3. Client Credentials: Used for server-to-server communication where the application acts on its own behalf, not on behalf of a user, and can authenticate with its own credentials.

   1. a client credentials can be used by the client itself to verify itself, for example I used it so that my jenkins can access aws that trusts the openprovider that I have.

4. Resource Owner Password Credentials: Allows the client to directly use the resource owner's credentials to obtain an access token. This is considered less secure and is discouraged unless absolutely necessary.

keyclock with azureAD

this is the flow for openID with keyclock and azureAD.

so for a provider to work fine it needs to provide these endpoints

1. Authorize Endpoint: This is where the OAuth 2.0 authorization requests are sent. It's responsible for user authentication and for obtaining user consent for the requested permissions. The response from this endpoint is typically an authorization code, which can then be exchanged for tokens at the token endpoint.

2. Token Endpoint: This endpoint is used to exchange an authorization code for an access token (and optionally a refresh token and/or ID token in the case of OpenID Connect). It can also be used to obtain new tokens when a refresh token is available.

3. .well-known/openid-configuration: This is a discovery endpoint for OpenID Connect providers that returns metadata about the provider's configuration in a JSON object. It includes information about the various other endpoints available (such as the UserInfo Endpoint, JWKS URI, etc.), supported scopes, response types, subject types, signing algorithms, and more. This allows clients to dynamically discover information about the OpenID Connect provider.

   Additionally, other useful endpoints in an OpenID Connect/OAuth 2.0 provider might include:

   • UserInfo Endpoint: An OpenID Connect endpoint that returns claims about the authenticated user.

   • JWKS URI (JSON Web Key Set URL): Provides the public keys that a client can use to verify the signature of tokens issued by the provider.

   • Introspection Endpoint: Allows clients to query the state of a token (active, expired, etc.) and obtain meta-information like scopes associated with it.

   • Revocation Endpoint: Enables clients to revoke access tokens or refresh tokens, enhancing security by allowing tokens to be explicitly invalidated before their expiration.

OpenID

openID is just a token that is sent back with the access token to give more info about the user.