OpenID Connect in Action
Metadata
Authors: copyright-2023-manning-publications.html Lists: Currently Reading Book URL: https://reader.bookfusion.com/books/5126028-openid-connect-in-action?type=pdf Date Added: 2024-11-09 09:05:39 UTC Last Updated: 2024-12-25 22:33:23 UTC Progress:
Highlights & Notes
1_The_OpenID_Connect_landscape
Date Created: 2024-11-16 19:30:34 UTC Color: 79cf76 ■
A grant type defines how a client application can get an access token from an OAuth 2.0 authorization server (see figure 1.2).
Date Created: 2024-11-14 05:28:55 UTC Color: 79cf76 ■
An attribute assertion: A strong statement about someone or something, which carries a set of attributes. Your driving license, for example, issued to you by the Department of Motor Vehicles (DMV) carries a set of attribute assertions: name, address, eye color, hair color, gender, date of birth, license number and so on. An authentication assertion: A strong statement issued with respect to how the OpenID provider authenticates the user during the login flow. The authentication assertion might be the username of the user and how the issuer authenticates the user before issuing the assertion. An authorization assertion: A strong statement issued with respect to the corresponding user’s entitlements. Based on the authorization assertion, the recipient of the assertion (or the client application) can decide how to act. When an issuer, for example, shares user’s age or date of birth with a client application, its an attribute assertion, but if the issuer says the user is entitled to buy a beer (if the user is old enough) without sharing the age, then its an authorization assertion.
Note
oidc assertions
2_The_cornerstone_of_OpenID_Connect
Date Created: 2024-11-16 19:35:02 UTC Color: 79cf76 ■
A grant type defines a protocol to request an access token
Date Created: 2024-11-16 19:36:40 UTC Color: 79cf76 ■
The following are the four main grant types along with the refresh token grant type highlighted in the OAuth 2.0 specification: Client credentials—Suitable for client applications that directly access resources with no end-users. The client application itself is the resource owner (we discuss this in section 2.3.1). A Weather App (the client application), for example, can use the client credentials grant type to obtain an access token, and use it to access the Weather API (the resource). Resource owner password—Suitable for applications the authorization server trusts (we discuss this in section 2.3.2). This should be avoided at all cost and the OAuth 2.1 specification has removed the resource owner password grant type.[3] Authorization code—Suitable for almost all the applications with an end user (we discuss this in section 2.3.4) Implicit—Don’t use it! (we discuss this in section 2.3.5). The OAuth 2.1 specification has removed the implicit grant type. Refresh token—Used for renewing expired access tokens. The refresh token grant type is little different from other four grant types listed above and we discuss the differences in section 2.3.3.