I have been reading about OAuth, and found that
it roughly performs the following
- client sends request token during redirect to server
- Server displays authorization screen to resource owner
- Resource owner provides uid and pw (not passed to client)
- Server sends access token back to client
- clients then users the Access token to gain access to a
resource
Based on my reding it does not appear that OAuth
does not enable SSO or Federation, but on some
Blogs it implies it does perform SSO
Is this correct or incorrect. Can it perform SSO
without the help of other protocols?
Thanks
Yes it supports SSO with this flow.
We have 2 applications A and B.
The user want to access application A
He is redirected to the identity profider (idp)
He logs in with his credentials.
The idp issues an OAUTH token and a cookie
The client now adds the oauth token to the request for app A and is authorized.
When the client wants to access application B he is again redirected to the idp
In this call to the idp the coockie that the idp had returned in the flow with app A is added.
Because of this the idp immediately returns a token for app B, the client does not have to log in again.
The client gan now access app B with the newly created token.
Hope this exmaple flow makes it more clear.
Related
I am new to OAuth and I am working on app identity/client credential work flow using OAuth. Basically there will be a client application calling the API using the client app's app id. The API will trust whoever have the access to the client app.
The understand I have for the implementation is that:
register client app to Azure AD
put the app id of the client app into the API
enable OAuth request so the client app is able to receive access token from AAD
use the access token to call the API
But my confusion is the relationship between the web app's app id and the access token. I know we have to put the client's app id into the API so the API can somehow recognize the client app. How does the API know the access token is from that specific app id? How does it work exactly?
The app id also named client id, it represents a client application which makes protected resource requests on behalf of the resource owner.
The client application authenticates the resource owner and obtains its authorization, then the authorization server will issue the access token to the client application.
For more details about the relationship, you could see the Azure Active Directory developer glossary.
Update:
For example, I use the client credential flow to get the access token for MS Graph API. Then I decode it in https://jwt.io/ . You will find the claims "aud": "https://graph.microsoft.com/", "appid": "xxxxxx", "app_displayname": "joywebapp2", for more details, see Claims in access tokens.
The you use the access token to call MS Graph API, it will know the access token is from that specific client app as you asked.
There is a dedicated protocol/validation mechanism for this. Once token is received at resource server (ex:- API as in your example), it can perform a token introspection to identify the context of the token. OAuth 2.0 Token Introspection define how the introspection request should be build and what to expect from response.
This specification defines a protocol that allows authorized
protected resources to query the authorization server to determine
the set of metadata for a given token that was presented to them by
an OAuth 2.0 client.
Read through the introspection response section to identify what sort of data it will return. Client ID is also some valid claim.
Now there is an alternative approach too. This is what Azure AD has adopted. Azure Active Directory use JWT formatted access tokens.
Azure Active Directory access tokens
Access tokens enable clients to securely call APIs protected by Azure. Azure Active Directory (Azure AD) access tokens are JWTs, Base64 encoded JSON objects signed by Azure. Clients should treat access tokens as opaque strings, as the contents of the token are intended for the resource only.
JWT tokens are self contained, which mean the holder/receiver can validate the integrity of the token and verify claims valid. Go through token validation section which explain the complete process. One key claim you must focus is the audience claim. This denote the intended audience of JWT and can have multiple values (array).
I have 3 applications, one is desktop application and this is my client, second is my Web Api to secure and the last one is api which checks if the user with password exists.
In my case I want to connect this flow with Azure AD.
I think this should work like this:
1.DesktopApplication sending request with clientid,clientsecret, username and password to AZURE
2.Azure sending request with username and password to my api where I can check this user exist if exist I will return "true"(or somthing like this)
3. If api return "true" Azure can return to DesktopApplication token
4. DoesktopApplication will send request ot secure Web Api with token
5.DesktopApplication recive content from secure Web Api
Api in 3 point is not same api in 5 point.
Is it posible to do this flow with Azure AD or not? And if not can I do something with my flow something to secure Web Api by Azure and still store users in my old db(oracle)?
It would be better to use OpenID Connect authentication flows to authenticate the user and acquire a token that way.
The approach you are suggesting has a few downsides:
You are storing a client secret in a desktop application, which can be easily extracted by anyone.
The authentication flow that allows you to do this will not work with users who have MFA enabled / are federated users (on-prem AD/MS account/Guest account) / have expired password.
It trains users to be phished as they really should only enter their password to the actual login page.
So it would be better to use a flow like this:
Your desktop application uses Azure AD Authentication Library (ADAL) or Microsoft Authentication Library (MSAL) to authenticate the user, requesting an access token for your API
Desktop app calls API, API validates token signature, issuer, validity time etc.
It will show the user a pop-up window where they can login, and as a result you'll get an Id token (which tells your desktop app who the user is) and an access token for the API.
I have 2 services, let's say A and B configured as web apps in azure. B needs a JWT bearer token to return a value. So when we try to call B from A, we Include the JWT bearer token in HTTP call from A using the Client Credential Grant flow explained here: https://learn.microsoft.com/en-us/azure/active-directory/develop/v1-oauth2-client-creds-grant-flow
Now the AAD registration of service B doesn't have localhost as it's reply URL but I noticed that I was able to talk to it from localhost. So Does AAD not respect reply URLs in client credential grant flow?
My understanding of reply URLs is this:
“In the case of a web API or web application, the Reply URL is the location to which Azure AD will send the authentication response, including a token if the authentication was successful.”
I'm using AuthorizationContext.AcquireTokenAsync() method with client credentials of App A and resource id of App B. So It should not return me the token to localhost because it's not configured?
Now the AAD registration of service B doesn't have localhost as it's reply URL but I noticed that I was able to talk to it from localhost. So Does AAD not respect reply URLs in client credential grant flow?
No, reply URLs define the destinations where AAD can send tokens after user authenticates.
In client credentials flow the tokens are sent in a response to a request from a program.
So they do not matter.
I already made the authentication flow with the Microsoft Graph/Azure AD authentication. Once I get the authenticated user's token I store them in his cookies. To validate the user's token I call the Microsft Graph API resource /me. This does not seem a good approach because basically everytime time a client does a request to my API, he is basically doing 2 requests because my API requests Azure AD for validation.
Is this a good flow?
No, it isn't.
Your front-end should acquire an access token for your API, which the API can verify using its digital signature.
The token will contain some info about the user as well as the app that acquired it.
The way in which the front-end acquires the token depends on the type of application.
Front-end single page apps use implicit grant flow for example.
Do note that you have to specifically ask for an access token for your API.
As long as your back-end is then configured with standard JWT Bearer authentication,
all is handled.
This is done by specifying the authority as your Azure AD tenant (or the common endpoint if it's multi-tenant),
and the standard bits for JWT authentication should download the public keys from Azure AD's metadata endpoint, which it can then use to verify validity of any access token it receives.
You do not have to validate tokens for an api that's not yours (issued to your AppId Uri).
For example, Graph validates the tokens that are sent to it (issued for "https://graph.microsoft.com).
If you build and register in Azure AD an Api of your own (say AppIdUri="https://myapi.mydomain.com"), your clients will request and receive access tokens with aud claim set to "https://myapi.mydomain.com".
The clients themselves don't need to validate the access token issued for your Api But your Api, when it receives those access tokens, has to validate them. The validations, among other things will validate the access token was issued to "https://myapi.mydomain.com".
Try out this sample, to get a good understanding around concepts of token validation.
I am using flicker PHP sdk phpFlickr-3.1 to access media content into a web application. I have successfully obtained the authentication token with required grants. I need to support the logout feature in web application. The logout from web application should either logout from yahoo account or it should revoke grants form authentication token.
Is there any API to logout / expire authentication token / remove grant permission from authentication token?
I'm not aware of an API to explicitly log out. However, you can simply discard the access token that you received from the OAuth workflow, once your access is complete. This will force your application to go through the workflow again, the next time your app needs access. Quoting from the docs, emphasis added:
After the user authorizes your application, you can exchange the
approved Request Token for an Access Token. This Access Token should
be stored by your application, and used to make authorized requests to
Flickr.