I have a ReactJs frontend making requests to an API. Both hosted in Azure with app registrations in AAD as well.
I used to be able to use v1.0 auth endpoint, and create a valid token for the API:
https://login.microsoftonline.com/common/oauth2/authorize?client_id=<AAD_WEB_APP_ID>&resource=<AAD_API_ID>&response_type=token ...
If I understand the documentation correctly, this type of auth flow isn't allowed/possible in v2.0:
However, that Web API can receive tokens only from an application that has the same Application ID. You cannot access a Web API from a client that has a different Application ID. The client won't be able to request or obtain permissions to your Web API.
The reason for changing from v1.0 to v2.0 is that I need access to Microsoft Graph (Groups in particular).
My question is: How can I create an access_token that works for Microsoft Graph and my API? If that isn't possible, what would the correct auth flow be?
You don't need to switch to the v2 Endpoint for this, Microsoft Graph supports both v1 and v2 tokens (actually, every API I can think of that supports v2 also supports v1 but there might be an exception I'm forgetting).
The steps are pretty straightforward:
Update your AAD registration in the Azure Portal and add the Permissions for Microsoft Graph you're going to be using.
Instead of passing resource=<AAD_API_ID> in your URI, use resource=graph.microsoft.com. This will return a token that can be used with Microsoft Graph.
Important: You must request the Offline Access scope (offline_access) for this to work.
Where this gets confusing is that technically you cannot use the same Access Token to access both your API and Microsoft Graph. What is supported is switching the Resource when refreshing your token. So while, yes, you are using two different tokens, you're reusing the same credentials/authorization code.
Here is an example flow:
A user authenticates using your API as the Resource (resource=<AAD_API_ID>). This returns an Authorization Code back to your application.
The application posts the Authorization Code to the /token endpoint (also using your API as the Resource). This will return both an access_token and a refresh_token to the application.
Use this access_token to make calls into your API.
The application posts the refresh_token to the /token endpoint using graph.microsoft.com as the Resource. This will return a new access_token and refresh_token keyed to Microsoft Graph.
Use this new access_token to make calls into Microsoft Graph.
The application again posts the refresh_token to the /token endpoint but this time using your API as the Resource again. This will return a new access_token and refresh_token keyed to your API.
Call your API
You can repeat this cycle as needed. Depending on how often you need to switch, you can also keep access tokens for both your API and Graph in memory and reuse them until they expire. Just be sure and always store the last Refresh Token you received so you can fetch a refreshed token for either resource as needed.
Related
I am building a React-based SPA that communicates with a spring-boot backend via a REST API. I need the user to be able to log into their Microsoft account on the browser client (the SPA) and I need the backend service (spring-boot app) to be able to query Microsoft's Graph API on behalf of that user.
After reading up on the Oauth2 flows, the authorization code flow (not the PKCE flow, just the regular authorization code flow) seems the most appropriate. The browser client could let the user log into their Microsoft account, retrieve an authorization code, and send the authorization code to our backend service via HTTP request. The backend service (which is trusted and can safely store a client secret) can then request an access token, make requests to the Graph API directly (meaning that the SPA would never need to make any requests to the Graph API), and silently refresh the token as needed.
However, I cannot see any examples of anyone using this flow to access Microsoft's Graph API.
Looking at Microsoft's documentation, it seems like they recommend using the on-behalf-of flow. But this flow requires the browser client to request an access token and then use that to communicate with the backend service (which in turn can communicate with the Graph API). It doesn't make sense to me why the access token cannot be requested on the backend using a client secret. Wouldn't this be a more secure and preferred method than having the client retrieve the access token, as is done in the on-behalf-of flow?
The Oauth2.0 site, recommends that SPAs should either use the authorization code with PKE or the implicit flow, but I do not see an option to use the standard authentication code flow for SPAs. Should I take this as an indication that SPAs should not be using the standard authorization code flow as I described earlier?
Despite not finding a clear-cut example of the standard authorization code flow in Microsoft's documentation for a react frontend + java backend, I tried to go about doing this myself. However, using the #microsoft/mgt-react and #microsoft/mgt-element libraries to do this are not straight forward. For example, the #microsoft/mgt-element notion of a Provider supports a call to retrieve an access token, but doesn't clearly expose the authorization code. If I wanted to do the authorization code flow described earlier, it seems like I would need to use raw HTTP requests, which I know is not a recommended way of accomplishing this.
Summarizing my questions:
What OAuth2.0 flow should I be using: 1) authorization code (access token is retrieved by backend service using client secret), 2)
authorization code with PKE (access token is retrieved by client), or
3) on-behalf-of flow (access token is retrieved by client, seems to be an extension of PKE flow)?
If using the on-behalf-of flow, does the SPA just include the access token in the header (marked as 'bearer') and the backend service just
includes that same header to query the Graph API, or does the backend
service need to request another token before querying the Graph API?
Agree with #ch4mp to call graph api directly in SPA if it's allowed. If not, then I recommend you using on-behalf-flow or client credential flow based on your requirement.
Let's come back to your requirement -- call ms graph api in a springboot api project. First, let's see one of the graph api getting user api. You can see permission types here: Delegated which means call graph api on behalf of the user, Application which means calling api on behalf of the application(your spingboot api project) itself. If you want to call api behalf of the user, then you have to use on-behalf-of flow. This is because the api project which will be considered as a daemon application, so the project itself doesn't have a UI page to let users enter username/password to sign in and get authenticated.
You can certainly use ROPC flow which have to pass the username/password to api but I really think it unsafe, so I don't recommend.
If it's not necessary for you to call graph api on behalf of user, you can certainly take client credential flow into consideration. But pls note here, application type api permission is a "large" api permission which always have name like User.ReadWrite.All, Mail.ReadWrite.All and it always means the application can not only query user information but also be able to modify user information.
If you want to use on-behalf-flow, then you may review this answer and it explained the whole progress...
I would use authorization-code flow (with PKCE) to get an access-token and then refresh-token flow to "maintain" this token, both from client.
Authorizing the request to your resource-server with this token only makes sense if Microsoft authorization-server is your main authorization-server. Otherwise (user also logged in with an authorization-server of your own or not using OAuth2 betwean React and backend), you can still send Microsoft access-token in request body.
In any case, when issuing requests in the name of the user from the backend, do as you suggest: just set the access-token sent by the client as Bearer Authorization header (token is retrieved either from Spring security context or request body). Backend fetches a new access-token (using client-credentials flow) when issuing requests in its own name (without the context of a user).
Side note: have you considered calling Microsoft API directly from React client? If you don't have to store the result of that call on your resource-server (i.e. call graph API to display data and store only what user selected from that data), that would save quite some latency on the client and costs (network and CPU) on the backend.
I have a scenario where I have an on-premise GUI application which has a "Web Service Invoke" component which I use to call a GAE API.
In the GUI application, it is possible to:
store credentials
create a chain of web services/http(s) calls that can integrate an output of preceding https(s) call as a query parameter or header value into the next http(s) call
retrieve a value from JSON response of the http(s) call
But it is not possible to programmatically do anything. The Web Service widget has fields for passing API URL, query parameters and headers only.
I'm looking to do a service-to-service authentication for the API call and the API should be protected using IAP as well.
I'm aware of the recommended approach is to create a service account and provide the service account JSON key file to the client and the client signs a JWT token and pass it as a bearer token. But as I only have widgets, no programming possible, therefore signing JWT token is not an option.
I was looking at Google OAuth or IAM APIs which can support "client_credentials" grant type wherein I can get an access token using just clientId and clientSecret - something possible in Apigee. But it seems this grant type is not supported by Google OAuth APIs.
I also looked at Cloud Endpoints using API KEY - so the current thought is to the client passes API KEY in header/parameter for authentication to Cloud Endpoints, then Cloud Endpoints uses its service account to get access through IAP, and finally, I'm thinking that the client can also send in "Basic Auth" credentials through Authorization header which the GAE API backend service validates. The additional "Basic Auth" is because Google recommends using another auth method in addition to API KEY.
I would like a simpler solution if possible using GAE and IAP only. Any other suggestions, especially using time-limited tokens, that can work over only http(s) calls (non-programmatic or client library), is much appreciated.
Any alternatives or things to try is also appreciated.
Look into this server-to-server authentication using JWT Google API Authentication
I need a solution for accessing Microsoft graph api with a token which never expires for a multitenant application.
I am using frontend as react and backend as lambda function.
Actual requirement
Need to connect Microsoft app (which will give access to graph api's) with project where same auth will be used by multiple users, same authentication should work until it revoked.
Take OAuth 2.0 auth code grant as an example.
Currently, access token lifetime cannot be configured to be permanent.
Therefore,You can Request an access token
and you can Refresh the access token when it expired.
I followed this tutorial to setup authentication for my Azure Bot. After a successful login, it returns a token for me. I believe that this is an authorization token to access the Microsoft Graph API. If I wanted to use this same token to exchange for an access token to another web application, is that possible? And how would I be able to do it?
Yes, it's possilbe.
You should be able to get a refresh_token after the authorization is finished.
Use this refresh_token to exchange another access_token with the scope of another web application. Like this:
Then we can get an access_token for another scope:
You can see that the scope has changed from https://graph.microsoft.com to api://{id}/user.write which is another web API.
UPDATE:
Maybe I have a misunderstanding because I see you want to exchange a new access token.
If you just want to access your own web api from Bot application and don't need to call Microsoft Graph API, just modify the Resource URL (Azure AD v1) or Scopes (Azure AD v2). It's unnecessary to exchange a new access token.
For Azure AD v1, you should set Resource URL as: api://{api id}.
For Azure AD v2, set Scopes as: api://{api id}/.default.
Please note that api://{api id} is your web api.
On my initial analysis on the fetching the access token from Azure AD using OpenID connect protocol, I came to know that there are two ways to consider
Fetching access token using the signed in user's context where caching is used.
Fetching access token using application context.
Can anyone help me to know which needs to be consider with some example code.
Fetching access token using the signed in user's context where caching is used.
OpenID Connect implements authentication as an extension to the OAuth 2.0 authorization process. It provides information about the end user in the form of an id_token that verifies the identity of the user and provides basic profile information about the user.
Please refer to code sample :Calling a web API in a web app using Azure AD and OpenID Connect ,this sample uses the OpenID Connect ASP.Net OWIN middleware and ADAL .Net. In controller , you could get access token for specific resource using the signed in user's context :
string userObjectID = ClaimsPrincipal.Current.FindFirst("http://schemas.microsoft.com/identity/claims/objectidentifier").Value;
AuthenticationContext authContext = new AuthenticationContext(Startup.Authority, new NaiveSessionCache(userObjectID));
ClientCredential credential = new ClientCredential(clientId, appKey);
result = await authContext.AcquireTokenSilentAsync(todoListResourceId, credential, new UserIdentifier(userObjectID, UserIdentifierType.UniqueId));
Fetching access token using application context.
What do you mean by "application context" ? If you are talking about OAuth 2.0 Client Credentials Grant Flow , which permits a web service (confidential client) to use its own credentials instead of impersonating a user, to authenticate when calling another web service. You could refer to this scenario explanation and code samples .
To fetch an access token to the graph API, you need to:
redirect the user to the Azure authorization endpoint (https://login.microsoftonline.com/common/oauth2/v2.0/authorize),
to get back an authorization token,
that you need to provide Azure with, on the access token endpoint (https://login.microsoftonline.com/common/oauth2/v2.0/token), with your application credentials.
Finally, you can provide this access token to the userinfo endpoint on the graph API: https://graph.microsoft.com/v1.0/me
with some example code
I've written a sample code, but it depends totally on the language, environment and OIDC library you are using. In case you are using Java in a servlet environment with the MIT implementation of OIDC (MITREid Connect), my example to access the Microsoft graph API by means of OIDC on Azure is available on GitHub here: https://github.com/AlexandreFenyo/mitreid-azure