Overall documentation: Article directory Github: github.com/black-ant

This article will talk about the old line – identity security related concepts, mainly to say the general identity authentication common several protocols

This article mainly says OAuth, OIDC, CAS. As for SAML, I seriously doubt that one article can finish….

A. The preface

I’ve tried to break down the agreements into a few broad categories:

  • Pure binding protocol: OAuth, SAML, OIDC, CAS
  • Server protocols: RADIUS, Kerberos, ADFS
  • Authentication methods: OTP, biometric authentication (face, voice print, fingerprint)
  • Authentication server (included) : AD and LDAP

In this article we will only give a general overview of the process, and then we will analyze the implementation of the process step by step.

1.1 Pre-knowledge knowledge Token

Token is one of the most common concepts in the authentication process. It has no specific specification, it is just a key with different protocol characteristics. In general, they are meaningless strings with some regularity

1.2 Pre-knowledge point JWT

JWT stands for Json Web token. JWT usually consists of three parts:

  • JWT header: The header is in JSON format
    • Alg: indicates the algorithm used for signature
    • Typ: indicates the type of the token, which is JWT
  • The payload
    • Iss: Issuer Identifier: Mandatory. The unique identification of the provider of authentication information
    • Exp: Expiration time: Expiration time after which ID tokens are invalid and will not be authenticated
    • Sub: Subject Identifier: topic. The EU identification provided by iss is unique within the scope of ISS. This is used by the RP to identify a unique user
    • Aud: user
    • NBF: Not available before this time
    • Iat: Issued At Time: JWT
    • Jti: JWT ID Identifies the JWT
    • Auth_time: AuthenticationTime: EU Time when authentication is complete
    • Acr: Authentication Context Class Reference: Optional. Represents an authentication context reference value that can be used to identify the authentication context class
    • Amr: Authentication Methods References: Optional. Represents a set of authentication methods
    • Azp = Authorized Party: Optional. Used in combination with AUD. This value is used only when the authenticated party and the audience (AUD) are inconsistent, and is rarely used in general
  • The signature

2. Pure constraint type

Purely constrained means that it looks like a specification, and different frameworks implement the specification (a specification is also called a framework, a narrow framework).

2.1 request

2.1.1 request to ramble

OAuth is usually referred to as its 2.0 version. Now OAuth has released its 2.1 version, which has been simplified in structure. OAuth is not a complete concept, it is actually composed of many different RFC (RFC 6749, RFC 6750), which build and add features to each other in different ways, as shown below:

@ Aaronparecki.com/2019/12/12/…

In the development of OAuth protocol, it has been gradually added several specifications, and achieve a variety of functions.

For example, RFC 6749 defines the four most common authorization types: Authorization code, implicit, password, and client credentials, while PKCE (a way to use authorization code flow without client secrets) has been added to RFC 7636 and recommended for native applications in RFC 8252.

>>> Until OAuth2.1 comes along, the following three types remain:

  • Authorization code + PKCE
  • Client Credentials
  • Device Grant

This article will not cover too much OAuth2.1, mainly because I have not written the implementation code…

OAuth2.0 supports:

  • Password mode (Resource owner Password Credentials)
  • Authorization Code
  • Simplified patterns (Implicit)
  • Client credentials
  • New Device Grant: Devices without a browser or keyboard

2.1.2 OAuth 2.0 process:

The OAuth process looks something like this:

  • Step 1: Use a method to authenticate and return a receipt AccessToken upon successful authentication (this is not limited to one Step).
  • Step 2: Use the returned ticket to obtain user information

OAuth2.0 process network has said too much, I think will not be better than the predecessors draw, here also directly quote:

Summary classification:

Here are the differences:

Code mode: The Code mode is generally used by enterprises because it is flexible and secure. It differs from implicit and password modes mainly in that there is a process to get Code:

Step 1: Authoriza -> code: initiate request return code Step 2: code -> Token: pass code for Toekn Step 3: Token -> UserInfo: Transfer a Token for user information

Implicit mode: Implicit mode is a simplified version of Code, which goes directly from Step1 Authoriza to the Token step

Password mode: The password mode changes a lot. It eliminates the step of login page authentication and directly obtains the Token

Request Code way

Request implicit way

Request the Password way

Overview of OAuth interface requests

// Authoriza Code mode* Step 1: HTTP://localhost:8080/oauth/authorize? response_type=code&client_id=pair&redirect_uri=http://baidu.com> Response_type -> return type > Client_id-> corresponding client ID > redirect_uri-> redirected address//localhost:8080/oauth/token? grant_type=authorization_code&code=o4YrCS&client_id=pair&client_secret=secret&redirect_uri=http://baidu.com> grant_type > code > client_id > client_secret > redirect_uri * Step 3: Exchange information by Token... Slightly -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --// Implicit mode (skip, the first step directly returns Code)


----------------------------
// Password mode (pass the Password directly)
http://localhost:8080/oauth/accessToken? grant_type=password&client_id=b7a8cc2a-5dec-4a64&username=admin&password=123456


Copy the code

2.1.3 request FAQ

Question 1: The role of state

Problem: When the attacked person (civilian A) logs in, A thinks that he logs in to his own account, but in fact, he logs in to the account prepared by the attacker (werewolf B). As A result, B can see all the operations A does on the account.

  • B prepares the attack account in advance, enters the first step of temporary authorization, and obtains the Code. At this point, the basic authentication has been completed, and the rest is to Access the authorization server to obtain the Access Token.
  • At this time, B forcibly stops the self-verification process and tricks A into clicking, so that A can complete the subsequent login through Code. At this time, A thinks that it is its own account that logged in and enters the system correctly

This is often referred to as a man-in-the-middle attack, and with state, developers can use this parameter to validate requests, record the user’s location in front of the authorization page, and, of course, prevent CSRF

Question 2: Scenarios where Implicit and Password exist?

Password from the request can be seen that there are certain security vulnerabilities, if there is no SSL + plaintext Password, it is simply to tell others the Password, and in my use, part of the application is to initiate background request, do not expect to jump, this time, Password can be used

Problem three: to be improved

TODO ~~~~~

2.2 OIDC agreement

OAuth, of course, to talk about the OIDC this brother, OIDC is actually very simple, is on the basis of OAuth joined the concept of OpenID, if you for convenience, reuse OAuth code is no problem. That is to carry an additional JWT on the basis of OAuth to pass user information

2.2.1 OIDC profile

OpenID Connetction: OIDC= (Identity, Authentication) + OAuth 2.0, which is a standard Authentication protocol based on OAuth 2 and builds an Identity layer through OAuth 2.0.

OIDC provides ID Token to solve the problem of third-party clients identifying users. In the authorization process of Oauth2, users’ identity authentication information is provided to third-party clients. ID tokens are wrapped in JWT format (thanks to the compactness and tamper-proof nature of JWT and the availability of UserInfo, see the JWT extension at the beginning)

OIDC constitutes information

- core: defines the core functions of OIDC in OAuth2Build authentication on top of, and use Claims to pass user information - Discovery: - Dynamic Registration: enables clients to dynamically register with the OP-OAUth of the OIDC2.0Multiple Response Types: Optional. Provides several new response_type for OAuth2 extension. - OAuth2.0Form Post Response Mode: Optional. An extension to OAuth2 that sends information back to the client via queryString and fragment urls. This extension provides a mechanism to post data to the client in the form form. - Session Management: Optional. Session management, which is used to regulate how the OIDC service manages Session information. - front-channel Logout: Optional. Front-end based Logout mechanism that allows the RP (the abbreviation will be explained later) to exit the OP's iframe: optional. Based on the logout mechanism of the backend, it defines how RP and OP communicate directly to complete the logoutCopy the code

2.2.2 OIDC Request Process

  1. The RP applies for authorization from the OP. The OP returns the authorization Access Token and ID Token, and uses the Access Token to request information to the User Info EndPoint
  2. The AuthN request is an OAuth 2 Authorization request, but the purpose is different. The OIDC AuthN Scope parameter must have an OpenID parameter
The RP (Client) sends a request to the OpenID Provider (OP).
The OP authenticates the End-User and obtains authorization.
The OP responds with an ID Token and usually an Access Token.
The RP can send a request with the Access Token to the UserInfo Endpoint.
The UserInfo Endpoint returns Claims about the End-User. 
  
+--------+                                   +--------+
|        |                                   |        |
|        |---------(1) AuthN Request-------->|        |
|        |                                   |        |
|        |  +--------+                       |        |
|        |  |        |                       |        |
|        |  |  End-  |<--(2) AuthN & AuthZ-->|        |
|        |  |  User  |                       |        |
|   RP   |  |        |                       |   OP   |
|        |  +--------+                       |        |
|        |                                   |        |
|        |<--------(3) AuthN Response--------|        |
|        |                                   |        |
|        |---------(4) UserInfo Request----->|        |
|        |                                   |        |
|        |<--------(5) UserInfo Response-----|        |
|        |                                   |        |
+--------+                                   +--------+

// Detailed steps:"OIDC single sign-on process > 1. The user clicks the login, trigger for OIDC - SERVER authentication request | - > request: Contains parameter URL to login after a successful jump address | - > response: return to 302, the Location point OIDC - SERVER, Set - Cookie setting the nonce cookies > 2. The OIDC - SERVER by authc request | - > client_id= implicit - client: a certification request of the client's unique identifier | - > reponse_mode = form_post: use the returns form form data | - > the payload = id_token: Returns a type id_token | - > scope = openid profile: return to contain the openid that a | - > state: equal to OAuth2 state, to ensure client consistency | - > nonce: Write the cookie value | - > redirect_uri: certification after the success callback address >3. OIDC - SERVER authentication request authc | - > client_id is valid, redircet_uri legality and a series of validation >4Guide the user login, and user login | - > resumeURL | - > username + password >5. Return a form form automatically submit | - > id_token: id_token for authentication information, namely OIDC core part, by a string of JWT format packaging | - > scope: users allowed to access the scope information | - > state: Similar | - > session_state: session state >6Validation data validity, structure state of their own login | - > client-side validation id_token effectiveness, ensure that the client receive id_token is oidc - sercer. Issued by the devCopy the code

OIDC interface demo ————> really do not remember which big guy’s case….


// OIDC intuitive process request address:
// Step 1: Initiate Authorize requests
https://${yourDomain}/oauth2/default/v1/authorize? response_type=code
&client_id=12345
&redirect_uri=https://proxy.example.com:3080/v1/webapi/oidc/callback
&scope=openid,email
&state=syl

// Step 2: Redirection returns after successful authentication
https://proxy.example.com:3080/v1/webapi/oidc/callback?code=pkzdZumQi1&state=syl

// Step 3 apply for a Token
POST https://${yourOktaDomain}/oauth2/default/v1/token? grant_type=authorization_code& code=pkzdZumQi1& redirect_uri=https://proxy.example.com:3080/v1/webapi/oidc/callback
client_id=12345& 
client_secret=gravitational
    
// Step 4: AccessToken
{
"id_token":"FW6AlBeyalZtDIRXxA0u5XBbZkLzjYzKUQBloxQXSSGPFmRS8eSfDu0A4nS4GF1aQP9PRxQk7gIh9bjaX99
aa4vDSzP1E2ajsgIomlNGhNxBqEDV5Exp0xISE9bZ4HUzM91pbzPPj7Bq5ZQUWcSuSVD0NAfkAoG6qDpbQfxPjWRyfthz3p
UEXwZe8Cz4eOXOM45UKB4Q0VnVSChVF84MWkeBFKzhrRNXd2dFv0HTlkQr6vXGlYsocMxR06wo38HvGiKjkUmL2YUyPOjZa
oUN4ovfwlwdGdjNR2GVcRsXzjxCPszJ9dTXztoL5wo2ycEpuxkkNp57BuZ9YRexoNnRHahFKH76XrFsTvdvAYk3fBVUqrO5
vvyxHAFrAIKpV0FvaMiBwKNfaE84oRC6aBXnzS3q4uVyGcHveHQMJB1temgB599rfVH3pBqurUmQCd0tVexRZj4PUkrDocf
8Z0QKkCD0eonH0Q1bRpQPY5vATiLkpF8RArU7wyB2FxhB3egtQBvwDgsVjyix7u8Cx4P9oy3IJje6SZfc6Lz61uEQttpVhy
qfzgFYUqVoQacw6rocCn3u61dM0moB"
"access_token":"IEZKr6ePPtxZBEd"."token_type":"bearer"."scope":"read:org"."expires_in":3600
}

// Step 5: Decode id_token
{
    "sub":"virag"."iss":"https://${yourOktaDomain}/oauth2/"."aud":"client_12345"."iat":"1595977376"."exp":"1595980976"."email":"[email protected]"."email_verified":"true"
}

// Step 6: Request the resource

Copy the code

2.2.3 OIDC Extended Documents

https://www.ubisecure.com/education/differences-between-saml-oauth-openid-connect/

https://www.okta.com/identity-101/whats-the-difference-between-oauth-openid-connect-and-saml/

https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols

https://yangsa.azurewebsites.net/index.php/2019/08/08/brief-summary-of-differences-between-oauth2-and-oidc/

https://www.c-sharpcorner.com/article/oauth2-0-and-openid-connect-oidc-core-concepts-what-why-how/
Copy the code

2.2.4 Additional knowledge points for OIDC

OIDC Discovery specification

/. Well-known/OpenID-Configuration). This API returns a JSON data structure that describes some of the services provided in THE OIDC and their support. In this way, the RP of OIDC service can no longer hardcode the OIDC service interface information

Session management

  • Session Management: Optional. Session management: Used to regulate how the OIDC manages Session information.
  • Front-channel Logout: Optional. Front-end based logout mechanism.
  • Back-channel Logout: Optional. Based on the backend logout mechanism.

The benefits of OIDC

  • OIDC enables identity authentication to exist as a service.
  • OIDC can easily implement SSO (across top-level domains).
  • OIDC is compatible with OAuth2 and can control protected API resources using Access tokens.
  • The OIDC is compatible with many IDPs and can be used as the OP of the OIDC.
  • Some sensitive interfaces of OIDC all require TLS. In addition, thanks to the security mechanism of JWT,JWS and JWE family, some sensitive information can be digitally signed, encrypted and verified to further ensure the security of the entire authentication process.

2.3 the CAS

CAS I can be too familiar, this is not casual and everyone bullshit ~~~~

2.3.1 CAS term

The CAS consists of the CAS Server and CAS Client

  • The CAS Server is used to authenticate users, just like storing the identity of the user who logs in for the first time
  • The CAS Client is a self-developed application that needs to access the CAS Server

Three terms for CAS

  • Ticket Granting Ticket (TGT) : A Ticket generated by the CAS Server based on the user name and password and stored on the Server
    • After caching, ST will be generated with TGC (because TGT can indicate that the user has logged in).
  • Ticket-granting cookie (TGC) : A cookie, granting user identity information, which is distributed by the Server to the Client
  • Service ticket (ST) : a one-time ticket generated by a TGT for authentication

2.3.2 CAS Process

  • When a user accesses the website for the first time and redirects to the CAS Client, the user is redirected to the login page of the CAS Server if no cookie(TGC or ST) is found
  • Enter the user name and password on the login page. After the authentication is successful, the CAS-server generates a TGT and uses the TGT to generate an ST
  • It then redirects a third time and returns the ST and cookie(TGC) to the browser
  • The browser returns with the ST to the desired address
  • The browser server receives the ST and then goes to the CAS-server to verify whether it is signed by itself
  • Then log in another CAS access website and redirect to CAS Server. The Server determines that this is the first time (but there is TGC, that is, cookie, so there is no need to go to the login page).
  • But now there is no ST, go to cas-server and apply for one and redirect to CAS-Server
  • The CAS-server generates an ST using TGT + TGC
  • The browser server receives the ST and then goes to the CAS-server to verify whether it is signed by itself

I know most people are too lazy to read, I am too, so I drew a picture!!

2.3.3 CAS FAQ

The biggest differences between CAS and OAuth are as follows:

CAS and OAuth are both authentication structures/protocols, while Token/ST is a way of belonging to a ticket and has no specific attribution

  • 1 Resource and User Information:
    • The first thing to make clear is that the two are not the same thing!
    • Resources are protected and can be accessed only after authentication is successful. Generally, CAS resources reside on the client and OAuth resources reside on the server
    • In the authentication system, user information is returned during login and after successful authentication, and exists either explicitly or implicitly on the server
  • 2 Nuances of the application process:
    • When the CAS completes the secondary authentication (after login), it can directly use the ST for authentication. One reason for this is that it recognizes the session and Token
    • During OAuth authentication, in addition to a temporary Code, another ClientSecret is required to determine whether the client is legitimate
  • 3 Client:
    • Based on the above point, the CAS view is that the client is basically the same, no matter what, just put the TGC in the Cookie
    • The client of OAuth is the same thing in business, but the identity of the client is handled artificially

Bills certified by CAS:

CAS writes the TGC to the Cookie, and the current authentication takes the TGC authentication from the Cookie, so if you want to do cross-browser login, you can do it here!

conclusion

This article is not only an inventory, but also a perfection of their own knowledge graph. There are a variety of authentication protocols, and conventional applications usually only need to choose the most appropriate one to achieve their own business.

Reference and thanks

Speak the truth, quite many, but remember the time did not write down the address, too lazy to find, directly wish everyone good health