About OAuth2, I believe many beginners have some questions. This article has collected these questions into a QA, which may help OAuth2 learners.

FAQ

  • What are the common scenarios for OAuth2?

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

  • What is the OAuth2 client?

    A client is only a OAuth2 client if it is registered as a client with the OAuth2 authorization server and has been given an exclusive client_id identifier. Client applications such as Android apps, IOS apps, and Web front ends also follow this principle; they themselves register to the OAuth2 authorization server to be OAuth2 clients, otherwise they are not OAuth2 clients and must be themselves, not the back-end services that support them.

  • Why are there two types of OAuth2 clients, public and confidential, and what are the scenarios for each?

    See rfc6749#section-2.1 for the definition, according to whether OAuth2 client itself has the ability to maintain the privacy of client credentials, and whether it can securely authenticate the client’s credentials through the authorization server to classify OAuth2 clients as confidential clients and public clients. Most of the back-end data services should be registered as confidential clients; can not guarantee the security of their own credentials should be registered as public clients, public clients are no client_sercet, directly registered to the OAuth2 authorization server to implement the client, not through the back-end application for access token relay are public clients, specific scenarios require direct connection to the authorization server Web applications, mobile applications belong to this category.

  • Should the access_token and refresh_token of OAuth2 be returned directly to the front-end?

    The ability to return to the front end depends on whether the front end is a OAuth2 client directly on the authorization server, if not, it cannot hold access_token and refresh_token. The issuing target for access_token and refresh_token can only be the OAuth2 client. If exposed, they are vulnerable to theft.

  • How should a non-OAuth2 client application get authorization status if it cannot hold access_token and refresh_token directly?

    When the authorization is successful, a mapping between the token and the user client side can be done with the help of session or cookie. Of course, an opaque token (Opaque Token) mapping can also be considered, depending on business considerations.

  • What is the scope in OAuth2?

    OAuth2 is an authorization framework that naturally delineates a scope (scope) to ensure that OAuth2 clients act within the established scope and do not overstep it. It plays a similar role to the role in RBAC in that it is used to restrict access to resources. The role is for the Resource Owner, while the scope is for the OAuth2 client. There is of course one exception openid, which is an identifier for OIDC 1.0 and is considered a keyword.

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

    Many developers don’t want to be 302 redirected to the login page provided by the authorization server when they click on authorization, but you have to understand the fact that there is not a fully trusted relationship between the OAuth2 client and the authorization server. When a delivery boy delivers to you, you want to issue him a temporary access code, not a common access code. Also ajax cannot safely handle 302 redirects in the OAuth2 authorization process, which is also a technical issue.

  • Can the OAuth2 client do user authentication?

    OAuth2 itself does not define how users authenticate their identity to the OAuth2 client, which is to be distinguished from user authentication on the authorization server here. The OAuth2 client can get authorization credentials when it completes authorization, but it does not get user information directly. If the authorization server provides a resource interface to get user information, the OAuth2 client can try to get user information to indicate the user’s identity through that interface, depending on whether the user has authorized the OAuth2 client to do so. The OIDC 1.0 supplement defines the details of the process by which the OAuth2 client authenticates the user.

  • What is OAuth2 client authentication?

    While OAuth2 clients of the confidential type are registered with the OAuth2 authorization server, they have to prove to the authorization server that they are legitimate clients according to some policies (Client Authentication Method). This allows them to invoke some OAuth2 specified endpoints, such as the /oauth2/token token endpoint, the /oauth2/revoke token revocation endpoint, and so on. Details about OAuth2 client authentication can be found in OAuth2 Client Authentication Filter Detail.

  • Why was OAuth2 password mode deprecated?

    To be precise, password mode has been removed from OAuth2.1, including OAuth0, okta and other well-known three-party authorization services.

    The password schema was created at a time when single-page applications like React and Vue had not yet emerged, not even frameworks yet. It was more like a transitional solution to solve a legacy problem. In legacy applications, users are used to giving their passwords directly to the client in exchange for access to resources, rather than jumping around to pull authorizations and confirm them. OAuth2 was designed at its inception to allow users to slowly shift from traditional thinking to this model. It breaks the delegated authorization model and reduces the security of OAuth2.

  • What is the resource server in OAuth2??

    Any server that contains a resource interface that needs to be accessed by OAuth2 clients carrying access_token can be considered a resource server, including OAuth2 clients, OAuth2 authorization servers can assume the function of a resource server depending on the business and architecture. From the user’s (resource owner’s) point of view, the servers that host the resource interfaces that the user can authorize can all be resource servers. The resource server can decode and verify the access token access_token and determine if this request is compliant.

  • Is it possible to use microservices without OAuth2?

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

Summary

This is the recent collection of questions, I believe it can help you. The OAuth2 thing is not simple, after nearly three years of intermittent learning, I only fully understand this thing. So you learners should not be anxious.

The most important thing to learn this is to understand its concepts and processes, which is far more important than the various frameworks. OAuth2 itself and the language is irrelevant.

Reference https://mp.weixin.qq.com/s/D-sP8rLKWMd7o_f5WvN3lw