I'm trying to implement an "On Behalf Of" flow using Java and ADAL4J. The application is registered in the B2C tenant, and requires access to graph api via our own facade to graph.
The steps I have so far are:-
1) Authentication - successful and redirects me to the application page.
2) Upon redirection I call to Azure with the client code to obtain the token(s).
3) The next step attempts to exchange tokens to that I can use the new token to call graph.
Steps 2 fails as it only returns an ID Token, the Access Token and Refresh Token are not supplied.
Am I attempting to do something that is not supported as I've been through most of the documentation and I can't see what I'm doing wrong. Some of the documentation from last year actually suggests that this flow is not supported - I'd like to confirm hence me asking the question here....
thanks
Azure AD B2C does not currently support "on behalf of" flows. You can vote for the feature here to help the B2C team prioritize it.
Access tokens will be available in the next few weeks! Stay tuned to the Azure blog.
Related
I have an API locked down by Azure B2C. Everything is configured correctly for my client app that consume this API. My question relates to the integration tests that accompany the API. While it's pretty obvious that authentication triggers a UI to sign in, how would one go about requesting a token for tests cases that require authentication without popping a UI up?
Right now I have to have a utility that allows me to grab an access token (by popping up a UI) and then using that in my test project. Ultimately it expires so all the tests fail. This makes sense but I'm wondering if anyone has come up with a way to automate the process of acquiring tokens using this library so that the test cases can acquire them without popping up a UI. Screen scraper?
It looks like you want the Resource Owner Password Grant Flow. B2C does not officially support this, but Azure Active Directory does.
Read these:
Can I use "Resource Owner Password Grant" flow with Azure AD B2C
https://blogs.msdn.microsoft.com/wushuai/2016/09/25/resource-owner-password-credentials-grant-in-azure-ad-oauth/
Note that in the scenarios where B2C is simply acting like AAD (local accounts), you can use this flow. But for other social identity providers like Facebook and Google, you cannot use this flow.
I like your original method which is to generate an access token outside the app, and paste it in. I recommend adding to that the Refresh Token you got, and code to acquire a new token using an existing refresh token. Something like this.
Let me know if this helps.
Based on the code sample mentioned at URL: https://github.com/Azure-Samples/active-directory-dotnet-webapp-wsfederation , I implemented an application that uses WS-Federation (ASP.Net WS-Federation OWIN middleware) to authenticate users from an Azure AD tenant. Now I am looking for an approach to query the Graph API later in my application to fetch additional claims information required from application point of view.
Here in this scenario, I would like to know whether it is possible to query the Graph API or not. Do I need to update the existing WS-Federation protocol to OpenId Connect.
Can anyone help me to provide their guidance here.
The ideal would be to move to OpenId Connect, which would allow you to take care of both sign in and API in a single setup and flow.
If you want to stick with your current ws-fed setup, you can layer oauth2 on top of your implementation and retrieve the access token you need any time after the sign in. We have a sample showing exactly that, see https://azure.microsoft.com/en-us/resources/samples/active-directory-dotnet-webapp-webapi-oauth2-useridentity/
Sorry I am still very confused, read everywhere telling me oath is a authorisation protocol but it appears using the azure ad oauth code grant, it does promote a login screen to authenticate against the directory, so is it not an authentication process? what is the relationship between the open id connect? thanks!!
the OAuth2.0 protocol has several flows that an identity provider (in your case Azure AD) may implement to support auth.
The Auth Code flow is in fact one of these used by apps to get access tokens for some api. The flow is quite simple, an app redirects the user to the identity providers /authorize endpoint. At this point the user enters their credentials, and the site redirects back to your application with an authorization code and can also issue an ID Token that represents a user (This is the OpenID Connect part). The app takes this code, and POSTs it to the /token endpoint and will be issued an access token and refresh token. With the access token, your app can access whatever api you've requested access for.
For Azure AD specifically, Microsoft has built libraries that handle all these flows and token caching so most of the complexity is abstracted away. There's some simple code samples that you can checkout that you may find helpful. The authentication protocols and scenarios doc for Azure AD may also be really helpful for conceptual information.
I'm trying to understand what is expected to fail (if anything) when using different Microsoft Graph REST endpoints with an access token that was obtained against the Azure 1.0 oauth endpoint (implicit flow). For example, I created a new app registration in Azure AD tenant, added the Microsoft Graph service and selected every single permission available - 66 in total. What I find is that I can use the access token I get from the https://login.windows.net/common/oauth2/authorize endpoint to execute basic directory queries against the https://graph.windows.net/ REST endpoint. However other things - like the "me" or OneNote REST endpoints fail with a 401 unauthorized error. As a side note - I can get ALL of these scenarios to work with the Azure 2.0 oauth endpoint and passing in SCOPES for my permission requirements.
So...based on all of that, I'm not sure if big parts of the Microsoft Graph endpoints are not expected to work in this scenario, or perhaps I'm passing in the wrong RESOURCE parameter when I redirect to the .../authorize endpoint to get my access code, or something else. So if there is any info that describes if this is not expected to be supported, or if it is other info we should know - for example, is there a different RESOURCE needed when using the 1.0 oauth endpoint (the only variable I'm seeing right now), or whatever. Any sort of specific details here would be appreciated.
Thanks.
An access token is available for one endpoint , you could check the aud(audience) claim in access token . That's why we suggest using microsoft graph api , since useing Microsoft Graph to build apps for organizations and consumers that connect to a wealth of resources, relationships, and intelligence, all through a single endpoint: https://graph.microsoft.com.
You said that execute basic directory queries against the https://graph.windows.net/ REST endpoint , so the access token could be used to call Azure AD Graph APi (https://graph.windows.net/) . If using that token to make microsoft graph api calls (https://graph.microsoft.com) , you can't do that since access token is not available for microsoft graph api endpoint .
Background
We are developing a multi-tenant SaaS product in Azure which has an AngularJS front-end and Web API back-end. We use Azure AD for authentication and have hooked it up with ADAL JS (using the OAuth2 implicit grant). Being a multi-tenant application, we allow customers to authenticate against their own Azure AD (which may or may not be connected to an on-premise AD).
So far this all works nicely. ADAL JS takes the user to the Azure login page and once the user has authenticated, an OAuth2 token is issued. This JWT token is then sent with all API calls as a bearer token where we have our own claims transformation process for mapping the incoming claims from Azure to our application claims.
Rather than specify individual users in the claims transformation process, we try to do it by AD groups. This allows our customers to have security groups in their AD and then our application will use that to map to the correct application claims.
The problem
The JWT token we receive does not contain a groups property, despite having set groupMembershipClaims to SecurityGroup in the AAD application manifest. I have since read in this tweet from Vittorio that
The implicit grant will NOT send those claims, as it returns the token in the querystring - it's easy to blow past max length
Upon further investigation, I also found this StackOverflow answer from Vittorio that says
I verified and in the implicit grant case you will receive groups always via the overage claim. Please refer to https://github.com/AzureADSamples/WebApp-GroupClaims-DotNet/tree/master/WebApp-GroupClaims-DotNet - it will show you how to process the overage claim to retrieve groups.
I had a look at the JWT token and it does not include any overage claim (identified by _claim_names and _claim_sources). I'm definitely a member of two groups in my Azure AD.
I also now appear to have two conflicting statements about whether it is possible to get group information (whether directly or indirectly) in the implicit grant token.
Question 1: Should I get an overage claim that I can use to get group information? If so, do I need to do anything to ensure that claim gets sent to me?
Graph API
Whether I can get an overage claim with a link to the user in the graph API or whether I have to manually craft the link to get the user's groups, I'm still a little unsure how I authenticate with the graph API.
I need to contact the graph API from the back-end after receiving a request with a bearer token (from ADAL JS).
Question 2: Can I send the same bearer token to the graph API to read that user's directory information? Or do I need to authenticate directly from my application to the graph API tenant in the context of the application rather than the user?
apologies for the confusion here. I will double check the statement about the overage, but in any case - for the sake of unblocking you quickly, let's assume that you need to get the groups manually without the aid of the overage claim. You cannot reuse the token you send to your Web API. That token is scoped to your app, and any other recipient will (or should) reject it. The good news is that the flow through which your backend can request a new token scoped for the Graph is easy to implement. See https://github.com/AzureADSamples/WebAPI-OnBehalfOf-DotNet - the details in your case are a be a bit different (your web API has the audience == clientid of your app) but the topology and the code/calls involved are exactly the same. HTH! V.