According to this documentation, the on-behalf-of flow is not supported in B2C:
Web API chains (On-Behalf-Of) is not supported by Azure AD B2C.
Many architectures include a web API that needs to call another downstream web API, both secured by Azure AD B2C. This scenario is common in native clients that have a web API back end, which in turn calls a Microsoft online service such as the Azure AD Graph API.
This chained web API scenario can be supported by using the OAuth 2.0 JWT Bearer Credential grant, otherwise known as the On-Behalf-Of flow. However, the On-Behalf-Of flow is not currently implemented in Azure AD B2C.
Can't I just pull out the JWT from the first Web API request and pass it along to the next Web API? I know technically, I can, but is there a reason I wouldn't want to?
This approach would only work if both Web API's are configured for the same B2C App. Maybe that is the difference. Is the documentation referring to 2 separate B2C apps maybe?
Reference: Access the JWT bearer token when using the JWT middleware in ASP.NET Core
The OAuth 2.0 On-Behalf-Of flow is related to a first resource, "https://resourceserver1", receiving an access token from a client; then exchanging this access token for another access token for access by the delegated identity to a second resource, "https://resourceserver2" without any user interaction; and then sending that access token to the second resource.
This Azure AD documentation explains the On-Behalf-Of flow.
Given this, two different applications are necessary for two different resources, which in turn can require two different scopes.
You can vote for this feature at B2C Support for on-behalf-of flow.
Related
I have an application (Blazor WebAssembly in my case but I believe this scenario applies to other application types as well) that uses the excellent (and convenient) Azure B2C login services to allow my users to register and log in using either a local account or some social accounts. In particular, I am supporting logging in with a Microsoft account. Once a user is logged in using his Microsoft account I want to give the user the option to save content on OneDrive without the user having to provide credentials again to access the Microsoft Graph API.
In the returned claims after logging in using Azure B2C API I see that there is a idp claim (that's how I can determine if the user is logged in using a Microsoft account) and there is also a idp_access_token claim but it is not a valid JWT to use against the Microsoft Graph unfortunately.
What is the nature of the idp_access_token? How can I use it to access the Microsoft Graph and request additional scopes?
Azure AD B2C receives an access token (idp_access_token) from the identity provider. Azure AD B2C uses that token to retrieve information about the user. See details here.
No matter whether idp_access_token claim is a valid JWT, it cannot be used to access Microsoft Graph or other additional scopes. As the document has stated, it is for retrieving information about the user. Usually the embedded IdP access token is used to call the services that the IdP hosts. But Microsoft Graph data is hosted in Azure AD, not Microsoft Account side.
Currently, if you want to call Microsoft Graph API for B2C tenant, you have to follow Azure AD Authentication protocols. For example, OAuth 2.0 authorization code flow.
If you want to call you own API protected by B2C, you should choose Azure B2C Authentication protocols. For example, OAuth 2.0 authorization code flow in Azure Active Directory B2C.
I have a Rest API that is used by different clients:
Browser, when using swagger
Postman, when calling API
Curl
Other HttpClients, jvm, Python and such.
I want all clients to get authenticated with Azure AD. So each of them has to have an email, authenticate itself in front of Azure AD and then pass some token to my Rest API, on the backend I will validate the token. I really don't understand which flow to use. The one that is closest to my scenario seems to be Credentials Flow but I still don't understand how it fits in.
This picture is what I am trying to achieve:
The OAuth 2.0 On-Behalf-Of flow (OBO) serves the use case where an application invokes a service/web API, which in turn needs to call another service/web API. The idea is to propagate the delegated user identity and permissions through the request chain. For the middle-tier service to make authenticated requests to the downstream service, it needs to secure an access token from the Microsoft identity platform, on behalf of the user.
Based on your scenario it is recommended to use On-Behalf-Of flow (OBO).
Our apis are being consumed by 3rd party deamon applications as well as client applications. For third party deamon application we can expose the api via the client credential oauth flow and for the client application(S) we use the implicit grant outh flow.
The challenge we are facing is that in case of the implicit grant flow the user details are fetched from the ACCESS TOKEN. But when the same api is used for the client credential flow the user details can not be fetched from the ACCESS token as it has only application specific details.
What is the the best api design approach to handle the above challenge ?
Do I need two set of api(s) one for integrating with client application and one for integrating with server application ?
Will the usage of any alternative oauth flow help ?
Refer to Authentication scenarios for Azure AD documentation, as you stated correctly user interaction is not possible with a daemon application, which requires the application to have its own identity. This type of application requests an access token by using its application identity and presenting its Application ID, credential (password or certificate), and application ID URI to Azure AD. After successful authentication, the daemon receives an access token from Azure AD, which is then used to call the web API.
The quintessential OAuth2 authorization code grant is the authorization grant that uses two separate endpoints. The authorization endpoint is used for the user interaction phase, which results in an authorization code. The token endpoint is then used by the client for exchanging the code for an access token, and often a refresh token as well. Web applications are required to present their own application credentials to the token endpoint, so that the authorization server can authenticate the client.
Hence, the recommended way is two have two version of api implemented with two different type of authentication based on your scenario.
Reference -
Daemon or server application to web API
Understanding the OAuth2 implicit grant flow in Azure Active Directory (AD)
I have developer an API that is secured by oAuth2 and Azure B2C. I now want to access that API from a legacy web forms application which is using Forms as it's authentication mechanism.
I have used hellojs successfully on the client side to trigger the authentication method in a separate browser window and then use the access token successfully to call my API but how do i do this from the server side?
All the examples I've seen when setting up oAuth2 involve securing an API using the OWIN middleware (e.g. with Facebook login, etc) but I need to retain the existing forms authentication and simply invoke code that calls the API and handles the access code/token etc.
If I need the backend system to make requests on behalf of a user, should I be storing the access token securely somewhere?
The simplest approach would be to have the users authenticate against B2C separately. Think of this in terms of "linking" their account in your Web Forms app to their B2C account. If you also request the offline_access from Azure B2C, you'll receive a Refresh Token that you can exchange for a valid Access Token when needed.
Ideally, you should pivot away from Forms authentication. It's a very outdated model. It may, however, be a non-trivial amount of work which is why many folks often choose to start with the "linking" strategy and only tackle Forms Auth when they're doing a larger refactoring of their app.
I have an Asp.Net Core 2.0 Web API running as a web app in Azure. My API is consumed by client applications which are windows service running on servers at various client sites. So, this is a "Daemon or Server Application to Web API" communications flow as described in Authentication Scenarios for Azure AD
I register the client application at each site as a separate unique app in Azure AD, obtain the ClientId and AppKey and send it to the respective site for their devs to use in their service to request a JTW access token from Azure AD to use in the authorization header when making an http request to my API.
This is all working just fine.
The question I have is this; is there any way, in this scenario, that I can identify which site is making the request? From what I understand, it doesn't seem like I can add custom claims to an OAuth2.0 access token, like can be added to an OIDC ID token.
If you register the apps yourself then you know all the client ids for each different site so your API could use the appid in the JWT access token (which is the client id) and cross reference it against a list of sites. Here is an example of a JWT token obtained using the client credentials grant type: