ChatGPT解决这个技术问题 Extra ChatGPT

OAuth v2 communication between authentication and resource server

I'm having some troubles understanding how OAUTH-v2 works.

The OAuth version 2 spec reads:

Accessing Protected Resources The client accesses protected resources by presenting the access token to the resource server. The resource server MUST validate the access token and ensure it has not expired and that its scope covers the requested resource. The methods used by the resource server to validate the access token (as well as any error responses) are beyond the scope of this specification, but generally involve an interaction or coordination between the resource server and the authorization server.

How does this interaction between resource server and authorization server work in practice?

How does the resource server determine that an access token it received is valid?

How does the resource server extract the allowed scope from the token to see if access should be granted to a particular resource? Is the Scope encoded in the access token, or does the resource server first have to contact the authorization server?

How is trust between the resource server and the authorization server established?

Access token attributes and the methods used to access protected resources are beyond the scope of this specification and are defined by companion specifications.

Can someone give examples for token attributes?

This is really a quetsion I am looking for since few days

E
Eran Hammer

The reason this is out of scope for the specification is the wide range of ways to accomplish this connection between the two entities. The main question is how complex is your deployment.

For example, do you have one server managing authentication and access, and a set of discrete services each with its own servers serving the API calls? Or, do you have just one box with one web server which handles both authentication/authorization and the API calls?

In the case of a single box, not much is needed as the entity issuing tokens is the same as the one validating them. You can implement tokens to use a database table key and lookup the record in the database (or memory cache) on every request, or you can encode the scope, user id and other information directly into the token and encrypt it using a symmetric or asymmetric algorithm.

Things get a bit more complex when dealing with a distributed environment, but not by much. You still issue tokens at the authorization server, but the resource server needs a way to validate those. It can do it by making an internal API available to the resource server to ask the authorization server to "resolve" the token (which can be fast in a local environment), or the two can establish a public/private key pair or symmetric secret and use that to encrypt everything the resource server needs into the token.

Self contained tokens are longer but offer much better performance per-request. However, they come with a price - you can't really revoke them while they are still valid (not expired). For this reason, self contained tokens should be very short lived (whatever is acceptable to you to leave access open after it was revoked - e.g. many sites use one hour), with a refresh token good for a year or more to get new tokens.


Is it true that if the entity issuing and validating tokens has no static white/public IP then service provider callbacks to client/resource owner can't be done through HTTP(s) thus requiring some more elaborate implementations?
Callbacks are not performed by the service provider but by the user's browser. Not sure exactly what you are asking.
What happens if you add some apis that resource server uses( the apis belonging to you ) .Should you then use oath2 authentication (client_credentials) establishing a safe machine-to-machine communication with the resource server ? In that case does that mean that all apis have to share the same key pair with the auth server ?
J
Jahan Zinedine

One example of resource- to authorization server API is the one at Google Developers Website.
It doesn't specify the format of the access token though, but the response seems pretty universally useful.


OIDC and id_tokens is something different from obaque access tokens.