QA of some high-frequency questions in OAuth2 learning

I believe that many beginners have some questions about OAuth2 . Fat brother collected these questions one by one and made them into QA , which may help learners.

OAuth2 related QA

Q: Some common scenarios of OAuth2 ?

A: OAuth2 is mainly used for API authorization and is a solution for authorization between cross- API services. It is suitable for scenarios such as single sign-on ( SSO ), authorization and authentication between microservices, and API open platform.

Q: What is an OAuth2 client?

A: Registering as a client on the OAuth2 authorization server and obtaining the exclusive client_id identification is the OAuth2 client. Client applications such as Android applications, IOS applications, and web front-ends should also follow this principle. They can only become OAuth2 clients by registering with the OAuth2 authorization server. Otherwise, they are not OAuth2 clients. They must be themselves, not the backend that supports them. Serve.

Q: Why are OAuth2 clients divided into two types: public and confidential , and what are the scenarios?

A: rfc6749#section-2.1 According to whether the OAuth2 client itself has the ability to maintain the privacy of the client credentials ( client credentials ), whether it can safely authenticate the client's qualifications through the authorization server, the OAuth2 client is divided into a confidential client and a confidential client. public client . Most back-end data services should be registered as confidential clients ; those that cannot secure their own credentials should be registered as public clients . Public clients do not have client_sercet , and register directly to OAuth2 authorization The execution client of the server and the public client that does not relay the access token through the back-end application, such as web applications and mobile applications that need to directly connect to the authorization server in some specific scenarios.

Q: Should the access_token and refresh_token of OAuth2 be returned directly to the front end?

A: Whether it can be returned to the front end depends on whether the front end is an OAuth2 client directly on the authorization server. If not, it cannot hold access_token and refresh_token , access_token refresh_token can only be issued to OAuth2 clients. If the exposed side is left open, it can be easily stolen.

Q: Since client applications that are not OAuth2 clients cannot directly hold access_token and refresh_token , how should they obtain the authorization status?

A: After the authorization is successful, a mapping between the token and the user client side can be performed with the help of session or cookie . Of course, it is also possible to calculate an opaque token ( Opaque Token ) mapping, depending on business considerations.

Q: What is scope in OAuth2?

A: OAuth2 is an authorization framework, and authorization must naturally define a scope ( scope ) to ensure that the OAuth2 client acts within the established scope and does not cross the boundary. Its function is similar to that in RBAC role , and it is used to limit the access rights of resources. role for the Resource Owner, and scope for the OAuth2 client . Of course, there is an exception openid , this is the OIDC 1.0 logo, it is a keyword.

Q: Can the login page and authorization confirmation page in OAuth2 be separated from the front and back ends?

A: Many developers don't want to be redirected by 302 to the login page provided by the authorization server when they click on authorization, but you have to understand that the relationship between the OAuth2 client and the authorization server is not a complete trust relationship. When the delivery boy delivers food to you, you definitely want to give him a temporary access code instead of a common access code. Also ajax cannot handle 302 redirects in OAuth2 authorization flow securely, which is also a technical issue.

Q: Can the OAuth2 client perform user authentication?

A: OAuth2 itself does not define how a user authenticates an identity to an OAuth2 client, which is to be distinguished from user authentication on the authorization server. The OAuth2 client can obtain the authorization credentials when completing the authorization, but cannot directly obtain the user information. If the authorization server provides a resource interface for obtaining user information, the OAuth2 client can try to obtain the user information through this interface to indicate the user's identity. Identity, which depends on whether the user has authorized the OAuth2 client to do so. The OIDC 1.0 supplement defines the detailed flow of OAuth2 client authentication for users.

Q: What is OAuth2 client authentication?

A: Although OAuth2 clients of the confidential type are registered with the OAuth2 authorization server, they need to prove to the authorization server that they are legitimate clients according to some policies ( Client Authentication Method ). So that they can call some OAuth2 specified endpoints, such as /oauth2/token token endpoint, /oauth2/revoke token revocation endpoint, etc. For details about OAuth2 client authentication, please refer to OAuth2 Client Authentication Filter Details .

Q: Why was the OAuth2 password mode abolished?

A: To be precise, the current password mode has been removed in OAuth2.1 , including OAuth0 , okta and other well-known three-party authorization service agencies have removed the password mode.

When the password mode was born, single-page applications like React and Vue had not yet emerged, and even frameworks had not yet emerged. It's more of a transition solution to address legacy issues. In traditional applications, users are accustomed to handing the password directly to the client in exchange for resource access rights, rather than jumping around to pull authorization and confirm authorization. When OAuth2 was born, it was designed to allow users to slowly shift from traditional thinking. It breaks the delegated authorization model and reduces the security of OAuth2 .

For more details, please refer to my previous related articles .

Q: What about the resource server in OAuth2 ?

A: As long as the server contains the resource interface that the OAuth2 client carries access_token to access, it can be considered as a resource server, including the OAuth2 client and the OAuth2 authorization server. The function of the resource server can be assumed according to the business and architecture. From the perspective of the user (resource owner), the server that stores the resource interface that the user can authorize can be a resource server. The resource server can decode and verify the access token access_token , and determine whether the request is compliant.

Q: Can microservices not use OAuth2 ?

Of course, OAuth2 is just one of the current solutions for microservice access control, not the only option.

Summarize

These are some questions that Fat Brother has been asked a lot recently, I believe it can help you. OAuth2 is not a simple thing. After nearly three years of intermittent learning, the fat brother completely understands this thing, so all learners should not be impatient. When learning is boring, let it sit for a while. The most important thing to learn is to understand it. The concepts and processes of OAuth2 are far more important than various frameworks, and OAuth2 itself is language-independent.

关注公众号：Felordcn 获取更多资讯

Personal blog: https://felord.cn