So, a basic OAuth2 flow using authorization grant type would normally go as follows, (assume OAuth Client=Quora, OAuth Server=Google, for eg. purposes):
User goes to Client, is redirected to Server sign in page for authentication.
User logins to Server, and Server returns an authorization_code to Client.
Client then makes a call with client_id, client_secret and authorization_code to Server to fetch the token.
Server validates and replies back with token.
Client can now access api/resources from Server with the token.
Now, if the user already logged in to say, Server first, then tries to access Client,
How will Client know that user is already logged in to Server, (as client cant access cookies from server domain)?
From where will the Client get the authorization code to fetch the access token?
Good question. Here's what happens:
Client is redirected to Server page for authorization.
Server (Google) has cookies set in the browser for THEIR domain only (from last time), and can see the user's information.
Server (Google) generates a NEW authorization code, and redirects BACK to the Client webapp with that code.
The Client app then makes an API call to Server with client_id, client_secret, and NEW authorization code token and gets a new access token.
Client app then creates a cookie (or uses local storage) to store this new Access Token and keep the user logged in.
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.
I am reviewing OKTA. I have two authorization servers configured, the default one and a custom one. I have a client (web app) that is configured and correctly logging in. I am getting back the expected id_token and access_token. The problem I am running into, is how do I call an api, that is expecting an access token from the second authorization server? How do I request an access token on behalf of the logged in user (default auth server) from the second auth server, without prompting the user to login again? This is all done in .net core mvc application.
In each of your applications you can check for an active Okta session. If found initiate the OIDC AuthN flow.
This is the endpoint on the client you can use to check for an Active Session
https://developer.okta.com/docs/api/resources/sessions#get-current-session
You can use the following authorize URL to get the access token or id token
{{url}}/oauth2/{auth server ID}/v1/authorize?client_id={client id}&response_type=token&response_mode=fragment&scope=openid&nonce=nonce&state=state&redirect_uri={redirect url}
Get the auth server ID from the URL when you see visit the server in the UI.
The above call needs an active session so if you signed the user the first time with 'default' auth server recently. You don't need to sign the user again to get to the token for the second auth server.
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).
Hi I'm just getting started on the v4 CTP so I can see me posting some basic questions as I get my head around it. I want to create a service provider so I'm looking at the WCF Oauth2
The first thing is when I go to login what is the format of the OpenID for use with the provided database? What is the process for this. I assume I'll get redirected to a screen where I put my password? And that interacts with the database?
Cheers, Chris.
The sample OAuth2 Authorization Server's database merely contains a couple of sample client entries so that the sample client can make requests. It has a users table that is automatically populated by each user who successfully logs in using their OpenID. So to your question regarding the "format of the OpenID" to use, any valid OpenID 1.1/2.0 identifier will work.
The OAuth2 authorization server sample doubles as an OpenID relying party in this respect, but its OpenID functions aren't the meat of the sample -- there are other sample OpenID RP sites that demonstrate more functionality in that respect. But being that OAuth2 auth server and OpenID RP are coupled in this way, the flow is that:
User visits OAuth2 Client site and indicates to the client that it may request access to user's data on the resource server.
Client redirects user to authorization server so the user may grant permission.
Authorization server prompts the user to log in, if not already logged in.
User enters OpenID
Authorization server redirects user to their OpenID Provider to log in using some credential (username/password, infocard, etc.)
OpenID Provider redirects user back to authorization server.
Authorization server sample then asks the user "do you want to share resource [x] with client [y]?" User confirms.
Authorization server records that user authorized client [y] to access [x] so that future requests from that client for that resource may be auto-approved without user intervention.
Authorization server redirects user back to Client with authorization grant.
Client receives the grant along with the user redirect and uses a direct HTTP request to the auth server to exchange that grant for an access token (and possibly a refresh token).
Client then includes the access token in HTTP requests to the resource server to access the user's private data.
I hope that helps.
I'm wondering what the reasons are for OAuth 1.0 to require a round-trip to the data provider to exchange an authorized request token for an access token.
My understanding of the OAuth 1.0 workflow is:
Requesting site (consumer) gets a request token from the data provider site (service provider).
Requesting site asks the data provider site to authenticate the user, passing in a callback.
Once the user has been authenticated and authorized the requesting site, the user is directed back to the requesting site (consumer) via the callback provided which passes back the now-authorized request token and a verification code.
The requesting site exchanges the request token for an access token.
The requesting site uses the access token to get data from the data provider site.
Assuming I got that right, why couldn't the callback simply provide the access token to the requesting site directly in step 3, eliminating step 4? Why is the request to exchange the request token for the access token necessary? Does it exist solely for consumers that require users to enter the verification code manually, with the thought that it would be shorter and simpler than the access token itself?
Joe,
With OAuth 1.0, it's important to keep in mind which pieces are happening "server-to-server" and which pieces involve the browser ("user agent"). The "point" of OAuth, if you like, is to get a server-side access token and secret to the consumer's back-end server, without ever having the secret pass through the browser.
With this in mind: when a user authorizes a request token, the "callback" happens through the user-agent, via HTTP redirection. In other words, any data (i.e. a verifier code and the request token but NOT the request token SECRET) in the callback is "seen" by the browser. This is why an access token (and secret) can't be parameters of the callback step: these need to be communicated directly from server-to-server, not via the browser.