I am trying to create oAuth 2.0 app and have decided to separate Auth server and Resource servers.
How should I go about maintaining state in Clients
Client will request for auth token to auth server. And auth server will verify and send in tokens. Till this part I understand. How should I now be using token. Should I be doing request to Resource server directly with access token and Resource server should verify that access token with Auth server? OR should I be first making request to auth server and then verify and forward request to Resource server?
The RFC (https://www.rfc-editor.org/rfc/rfc6749) suggests:
(F) The resource server validates the access token, and if valid,
serves the request.
but also that:
The interaction between the authorization server and resource server
is beyond the scope of this specification.
My instinct would be to have your resource server receive a request and then either validate the access token itself if possible - and otherwise query the auth server as necessary rather than have the auth server proxy requests.
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 that 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.
The method in which the client utilizes the access token to
authenticate with the resource server depends on the type of access
token issued by the authorization server. Typically, it involves
using the HTTP "Authorization" request header field [RFC2617] with an
authentication scheme defined by the specification of the access
token type used, such as [RFC6750].
Related
Please refer to this video, specifically from 20.00 to 25.00.
https://azure.microsoft.com/en-us/resources/videos/new-authentication-model-for-web-mobile-and-cloud-applications/
The work flow he describes is this:
Client app connects to authorization end point through the browser. User enters credentials, and authserization server authenticates the user and sends the auth code using a re-direct. Client app intercepts the browser activity and extracts the auth code. A new request is made to token end point together with this auth code, client id and few other information. In return, app gets access and refresh token.
What stops some one from stealing the auth token in the first step (say through browser history), and then contacting the token end point to get access and refresh tokens?
First off authorization code is only good for about 3 minutes normally. Second authorization code can only be used once. Third redirect uri must be a valid one that was registered for this client on the oauth server
The client initiates the flow by directing the resource owner's
user-agent to the authorization endpoint. The client includes
its client identifier, requested scope, local state, and a
redirection URI to which the authorization server will send the
user-agent back once access is granted (or denied).
The authorization server authenticates the resource owner (via
the user-agent) and establishes whether the resource owner
grants or denies the client's access request.
Assuming the resource owner grants access, the authorization
server redirects the user-agent back to the client using the
redirection URI provided earlier (in the request or during
client registration). The redirection URI includes an
authorization code and any local state provided by the client
earlier.
The client requests an access token from the authorization
server's token endpoint by including the authorization code
received in the previous step. When making the request, the
client authenticates with the authorization server. The client
includes the redirection URI used to obtain the authorization
code for verification.
The authorization server authenticates the client, validates the
authorization code, and ensures that the redirection URI
received matches the URI used to redirect the client in
step (C). If valid, the authorization server responds back with
an access token and, optionally, a refresh token.
#section-4.1
Oauth flow
Lets do this with some correct terminology.
Client = your application
authority= identity or oauth2 server (authority)
resource owner = user whos data you wish to access.
Resource owner loads client, client notices that resource owner is not authorized. Resource owner contacts authority identifying itself using a client id and possibly a client secret and sending a redirect uri, and requests scopes. (some of the things sent depend upon the setup of the auth server)
Authority notices this resource owner is not logged in prompts them to log in. Resource owner logs in and checks what scopes the client originally requested. Prompts resource owner to grant client access to said scopes.
Resource owner consents to access. Authority returns to the client an Authorization code.
Client says nice i have an authorization code and returns to the authority the authorization code and its client id and secret. This way the Authority knows that this is in fact the client that the resource owner authorized.
Authority then returns an access token back to the client that it can use for the next hour.
Access tokens are not then re-validated. So if someone stole this access token they would be able to use it until it expires.
When a client send a request to resource service with OAuth access token,
how resource service check the access token?. Does resource server validate access token against some entity ?
When resource server get a request with a OAuth access token, it have two options to validate the access token.
First option is to contact token introspection endpoint of the authorization server. This endpoint is a standard endpoint defined by RFC7662 which is a part of OAuth 2.0 specification. According to that spec. resource server can will send a token introspection request to authorization server. If access token is valid (ex:- Not yet expired) then response will contain a active=true state. Please go through RFC7662 to understand how this works.
Second option is to use self contained token. In this approach, authorization server issue JWT based access tokens. Once resource server receive this token, it can go through contents of JWT to identify validity of the access token.
The validation of the token against a specific operation on a specific resource is done using oauth2 scopes
The way the resource server performs the validation itself depends on the implementation, the simplest way is to use "self contained tokens" e.g. JWT ones so you can get the scopes from the token itself without additional lookup.
If your server exposes resources using traditional http REST semantic, the simplest implementation is to use an http middleware / filter which just check the resource uri and the http verb to determine the validity of the operation
RFC claims that (Figure 1):
(A) The client requests authorization from the resource owner. The
authorization request can be made directly to the resource owner
(as shown), or preferably indirectly via the authorization
server as an intermediary.
Does this mean that upon request from the owner of the resource authentication protocol is not used?
Or what does it mean?
This means that the client can request the resource onwer credentials in both ways:
Directly to the resource owner, asking for user and password to the resource owner and then sending them to the authorization server,
Or preferably via the authorization server, for example when you use your google or facebook account to authenticate in a web site.
I am currently trying to implement a web service (API) with OAuth2 authentication using Spring Security OAuth. As far as I understood, given a user, a client app and a server, the authentication process is as follows:
User requests resource from server via client
Client retrieves request token from server
Server responds with a temporary request token and a redirect URL
Client loads web page (redirect URL) and lets user enter credentials in order to authenticate the request token. The form inputs are sent to the server, input is unknown to client.
Server replies with an authorization code, which is handed to the client
Client uses authorization code to retrieve an access token (and, optionally, a refresh token if one was requested)
User hands access token to client
Client uses access token to retrieve requested resource
In Spring OAuth, there are three grant types to request an access token:
Authorization Code, which is the method I described above, refresh token, and user credentials. I don't know how retrieval by user credentials works, is it similar to retrieval via refresh token?
A couple of statements you are making above are incorrect. Probably it's a good idea if you have another look into the OAuth2 spec: https://www.rfc-editor.org/rfc/rfc6749
To concentrate on your question I just refer to the last paragraph of your question here after.
OAuth2 supports 4 grant types, namely 'Authorization Code', 'Implicit', 'Resource Owner Password Credentials' and 'Client Credentials'. The one you are refering to as 'user credentials' would be 'Resource Owner Password Credentials'. In this grant type you loose OAuth's benefit of not having to hand over resource owner (aka user) credentials to the client. However it still has the benefit of not having to store the password on the client and sending it for each resource request, since a token is used instead. The process flow is as following:
resource owner sends credentials to client
client sends credentials to authorization server
server returns access token (and optinally a
refresh token)
client uses access token in subsequent request to
ressource server
So yes, you could say that the flow of the Resource Owner Password Credentials grant is similiar to the flow when a client already has a valid refresh token (from which ever grant).
Generally OAuth definition says that it is way where user gives an application access to his resources stored in other application (without exposing the actual username and password). But inside Owin, it is a way to implement token based authentication within an application. Although we can deploy the Authorisation application at different server. But crux remains the same. Could anybody shed some light. I am very confused.
Thanks in advance
If you take a look at the OAuth 2.0 spec you will find this:
The authorization process utilizes two authorization server
endpoints (HTTP resources):
o Authorization endpoint - used by the client to obtain
authorization from the resource owner via user-agent redirection.
o Token endpoint - used by the client to exchange an authorization
grant for an access token, typically with client authentication.
As well as one client endpoint:
o Redirection endpoint - used by the authorization server to
return
responses containing authorization credentials to the client via
the resource owner user-agent.
Not every authorization grant type utilizes both endpoints.
Extension grant types MAY define additional endpoints as needed.
So basically, you have 2 options:
1) Use the authorization endpoint where your end-user is redirected to a form that is handled by the authorization server
OR
2) Create your own form inside your app, get the end-user credentials and send that data to the authorization server, where it will be validated and return a token for you to use.