The OAuth 2 spec leads me to believe that the "resource server" and "authorization server" do not necessarily have to be the same application but I'm struggling to figure out how this is actually implemented in practice.
As an example, suppose the following apps exist:
Scenario #1: Logging in to web frontend
Scenario #2: Authorizing third-party app
The part I'm having trouble understanding is how to authenticate the user before showing the allow/deny form in scenario #2. The user may be logged into the main web app but the auth service has no idea about that and would somehow need to authenticate the user again. Does the auth service need to support login/sessions as well?
I'm wondering if it might make more sense for the web app to be responsible for showing the allow/deny form for two reasons:
Here's one possible alternative to scenario #2:
What's the best way to handle this? Any general comments, advice, etc. would be awesome!
Thanks
The server that hosts the protected resources. It can use access tokens to accept and respond to protected resource requests. The resource server might be the same server as the authorization server. A grant that represents the resource owner authorization to access its protected resources.
OAuth 1.0's consumer, service provider and user become client, authorization server, resource server and resource owner in OAuth 2.0. OAuth 1.0 does not explicitly separate the roles of resource server and authorization server.
If the attacker violates the auth server, he has all your credentials, and can more easily violate every aspect of your systems by impersonating legitimate users.
In the context of OAuth 2.0, a resource server is an application that protects resources via OAuth tokens. These tokens are issued by an authorization server, typically to a client application. The job of the resource server is to validate the token before serving a resource to the client.
OAauth2 framework docs : https://www.rfc-editor.org/rfc/rfc6749
(A) The client requests an access token by authenticating with the authorization server and presenting an authorization grant.
(B) The authorization server authenticates the client and validates the authorization grant, and if valid, issues an access token and a refresh token.
(C) The client makes a protected resource request to the resource server by presenting the access token.
(D) The resource server validates the access token, and if valid, serves the request.
(E) Steps (C) and (D) repeat until the access token expires. If the client knows the access token expired, it skips to step (G); otherwise, it makes another protected resource request.
(F) Since the access token is invalid, the resource server returns an invalid token error.
(G) The client requests a new access token by authenticating with the authorization server and presenting the refresh token. The client authentication requirements are based on the client type and on the authorization server policies.
(H) The authorization server authenticates the client and validates the refresh token, and if valid, issues a new access token (and, optionally, a new refresh token).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With