Refresh Token: Refresh tokens doesn’t contain any authorization related information, as a result, cannot be used to make any authorization or authentication decisions.Access tokens can be JWT or SAML tokens (token formats are described below). The resource server makes authorization decisions based on the content of the access token. Access Token: Access tokens are issued by the Authorization server to the client, which in turn is presented to the resource server.There are three types of tokens that are commonly used: These tokens are created and secured by the Authorization Server and are transmitted over the network by all the roles in the flows. The tokens contain all the required information, that can be used by the resource server to make an authorization decision. Tokens are packages that carry authorization decisions, that can be transmitted from one security boundary to another. This would be an installed application in the machines, a PowerShell script, or a mobile application. Native Application: The native applications are unsecured applications that are installed and runs on the device the resource owner owns.A very common example is a JavaScript-based SPA application (ReactJs, AngularJs, AJAX etc.) running in a user’s web browser. Unsecured/Public Application: These are the application which runs in an unsecured environment, and there is a very good chance that some unauthorized person has access to these executing environments.A very common example of these are, a website/web service hosted on a web server. A secure environment is an executing environment, which can be considered relatively safe from outside or unknown authorized access. Secure/Confidential Application: These are the application which runs in a secure environment.OAuth 2.0 categorized the application into three major categories, and the flow differs based on these: Here is the diagram depicting the basic authorization flow. While doing that, she wants a calendar item created for each of them in her Outlook web calendar, so that she gets a reminder for her tasks when it is due. Scenario: Alice wants to use a TODO application to create and store a list of things she needs to do on a daily basis. To explain the roles clearly, here is a scenario: Authorization Server: The authorization server will store the identity information of the resource owner and issues token to be used in the flow.The client needs to access these resources on behalf of the resource owner to perform the operation. Resource Server: The resource server stores the resources the client needs to access to perform the required operation.In Azure AAD, this is represented as the AAD Application.

The client usually has a unique client_id and a password, also known as client_secret.

Client: The client is the application who is trying to do the operation, that the resource owner has asked it to do.

The resource is essential any data owned and generated by the owner, e.g.

Resource Owner: Resource owner is the user which is trying to perform an operation, on a resource.

The OAuth 2.0 protocol identifies four roles or personas for the delegated access flow: The document focuses on the implementation of the OAuth 2.0 and OpenID connect framework for Azure Active Directory AuthN and AuthZ flows, with endpoints specific to Azure Active Directory. This extension is called as OpenID connect. There is an extension of the OAuth 2.0 protocol, which merged the concepts of OpenID with OAuth to provide authentication capability. Please note the OAuth 2.0 protocol is designed for authorization purpose only and cannot be used for authentication. To better explain the OAuth 2.0 protocol flow, there are a few concepts that are widely used and accepted, as explained below. The OAuth 2.0 protocol is widely accepted to provide capabilities to Web API to make authorization decisions, without requiring for the clients to pass the credentials to the Web API. The term delegation in here means the user lets an application access its data in it its behalf. The OAuth 2.0 protocol is an open standard for delegated authorization scenarios.

Oauth and automize