OAuth

OATH 2

• A security standard where you give one application permission to access your data in another application.
• Instead of giving them your username/password, you give them a key which gives them specific permission to access your data or do things on your behalf in another application.
• Authorization = the steps to grant permission/consent

OATH Flow

• The visible steps to grant consent and invisible steps where the two servers agree on a secure way of exchanging info.

Authorization Code Flow

• The most common OATH Flow.

Resource Owner

• You, you are the owner of your identity, your data, and any actions that can be performed with your accounts.

Client

• The application that wants to access data or perform actions on behalf of you, the resource owner.

Authorization Server

• The application that knows the resource owner where the resource owner already has an account.

Resource Server

• The application programming interface, api, or service, the client wants to use on behalf of the Resource Owner

Authorization Server and Resource Server

• Can be the same or different
• Authorization Server can be a 3rd party service that the Resource Server trusts.

Redirect URI

• The URL the Authorization Server will redirect the Resource Owner back to after granting permission back to the client.
• Callback URL

Response Type

• The type of information the client expects to receive.
• Usually Code.
• The Client expect to receive an authorization code.

Scope

• The granular permissions the client wants such as access to data or perform action.

Consent

• The Authorization Server takes the scopes the Client is requesting and verifies with the Resource Owner if they want to give the Client permission.

Client ID

• Used to identify the Client with the Authorization Server.

Client Secret

• A password that only the Client and Authorization Server know.
• This allows them to share info privately behind the scenes.

Authorization Code

• A short lived temporaty code that the Authorization Server sends back to the Client.
• The Client then privately sends the Authorization Code back to the Authorization Server along with the Client Secret in exchange for an Access Token.

Access Token

• The key the Client will use from that point forward to communicate with the Resource Server.
• This is like a key or key card that gives the Client permission to request data or perform actions with the Resource Server on your behalf.

Client and Authorization Server established a relationship before anything else happens. The Authorization Server gave the Client a Client ID and Client Secret.

OpenId Connect OIDC

• Thin layer that sits on top of OATH that adds functionality around login and profile info about the person who is logged in.
• Instead of a key, OIDC is like giving the Client Application a Badge.
• The badge not only gives the Client specific permissions, it also provides some basic information about who you are.
• Where OATH enables authorization from one app to another, OIDC enables a Client to establish a login session often referred to as Authentication, as well as to gain info about the person logged in, the Resource Owner, often called Identity.
• OATH 2.0 is designed only for Authorization, for granting access to data
• When an Authorization Server supports OIDC, it is sometimes called an Identity provider since it provides info about the Resource Owner back to the Client.
• Enables scenarios where one Login can be used across multiple applications, also known as Single Sign On SSO.v
• Add scope=OPENID in addition to ClientID, RedirectUri,ResponseType.
• In addition to the AccessToken, we also get back an ID Token.

ID Token

• This is a JWT
• Client can extract info from the JWT, such as Id, Name, etc.
• The data inside the JWT are called Claims.