OAuth stands for Open Authorization.It’s a process through which an application or website can access private data from another website. It provides applications the ability for “secure designated access.” For example, you can tell Google that it’s OK for abc.comto access your google account or contact without having to give abc.com your google password.
The OAuth 2.0 authorization framework is a protocol that allows a user to grant a third-party website or application access to the user's protected resources, without necessarily revealing their long-term credentials or even their identity. The Oauth technology is widely used for application security andthe latest version of Oauth 2.4.x is popular. With invent of Spring Security 5.2, both integrated Oauth is preferred.
CloudPrisma has expertise in Azure application Security setup for OAuth. OAuth 2.0 is a security standard where you give one application permission to access your data in another application.The steps to grant permission, or consent are often referred to as authorization or even delegated authorization You authorize one application to access your data, or use features in another application on your behalf,without giving them your password.
Resource Owner: 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 action on behalf of 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.
RedirectURI: The URL the authorization server will redirect the resource Owner back to after granting permission to the client. This sometimes referred to as the“Callback URL”.
ResponseType: The type of information the client expects to receive. The most common Response Type is Code, where Client expects an authorization Code.
Scope:These are the granular permissions the client wants, such as access to data orto perform actions.
Consent:The authorization server takes the scopes the client is requesting and verifies with the Resource Owner whether or not they want to give the client permission.
ClientID: The ID is used to identify the Client with the Authorization Server.
ClientSecret: This is a secret password that only the Client and Authorization Server know. This allows them to securely share information privately behind the scenes.
Authorization Code: A short lived temporary code the client gives the Authorization Server in exchange for an Access token.
AccessToken: The key the client will use to communicate with the Resource Server.This is like a badge or key card that gives the Client permission to request data or perform actions with the Resource Server on your behalf.
OAuth solves the delegated authorization problem, but it doesn’t provide a standard way to authenticate the user. You could say that, OAuth 2.0 is for authorization.
OpenIDConnect is for authentication.
Authentication is the identity assurance that the communicating entity is the one claimed.
Authorization is the process of verifying whether the communicating entity has access to the resource.
In other words, authentication cares who you are, authorization cares what permissions you have.
OpenID Connect is an identity layer on top of the OAuth 2.0 protocol. It extends OAuth2.0 to standardize a way for authentication.
The Story: The client application presents its client credentials (client identifier and client secret) to the authorization server requesting approval to access the protected resource(owned by the client application) on the resource server. The authorization server authenticates the client credential and issues an access token.
The client sends a POST request with following body parameters to the authorization server
