I am trying to create an online meeting with a web application using the Microsoft Graph API.
When I try to initiate an authorization request to get permissions from the end-user to create a token with a similar URL to:
https://login.live.com/oauth20_authorize.srf?state=xxx&scope=https%3A%2F%2Fgraph.microsoft.com%2F.default&response_type=code&approval_prompt=auto&client_id=xxx
I get the following error message from the Microsoft API:
The client does not have a secret configured. If you are the client
application developer, configure a secret through the application
management site at https://go.microsoft.com/fwlink/?linkid=2083908.
I have a secret configured for the application in the "Certificates & secrets" part under the "Client secrets":
I have no clue what I am missing here and the Microsoft documentation is not really helpful.
The solution was to change the authorize and token endpoint to https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize and to https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token respectively as it is described here.
In my case - since I want to support multiple tenants - I could not fill out the {tenant} part of the URL with the actual tenant id, but I needed to set organizations since as it is described here only work or school accounts are supported.
So the final URLs changed to the following:
Authorize: https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize
Token: https://login.microsoftonline.com/organizations/oauth2/v2.0/token
Related
I have had been struggling to make my Azure Active Directory Oauth 2.0 Client Credentials Flow work with API Management. but I get authenticated via postman too. But in return I do not get any access token just a bunch of HTML. How can I fix this? The settings of the applications are exactly as per the documents including the validation of JWT Policy.
Basically I want my client apps to connect with my azure API's using Oauth 2.o without any consent using provided client id/secret. I'm trying to set this up for now with ECHO API provided out of the box with API Management console.
thanks
Postman Access token Error Screen
To use application permissions with your own API (as opposed to Microsoft Graph), you must first expose the API by defining scopes in the API's app registration in the Azure portal. Then, configure access to the API by selecting those permissions in your client application's app registration. If you haven't exposed any scopes in your API's app registration, you won't be able to specify application permissions to that API in your client application's app registration in the Azure portal.
For an example, if I sent scope parameter with custom name like https://testwebapp.in/.default without configuring same as application ID URI in Azure AD then is an expected behavior and you will get error AADSTS500011.
scope parameter in the request should be the resource identifier (application ID URI) of the resource you want, affixed with the .default suffix. For the Microsoft Graph example, the value is https://graph.microsoft.com/.default. This value tells the Microsoft identity platform that of all the direct application permissions you have configured for your app, the endpoint should issue a token for the ones associated with the resource you want to use.
Reference: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow#application-permissions
I created a new app service and set accessTokenAcceptedVersion to 2 in manifest.json as I am looking for a v2 token similar to here. However the accessToken generated by Microsoft always has an iss value of sts.windows.net when decoded. I would like it to be login.microsoftonline.com. Please advice.
This is my implementation:
This is my token when decoded:
Please advice.
Please see this part (just in the link you shared):
Resources always own their tokens (those with their aud claim) and are
the only applications that can change their token details. This is why
changing the access token optional claims for your client does not
change the access token received when a token is requested for
user.read, which is owned by the Microsoft Graph resource.
It means that the accessTokenAcceptedVersion setting should be configured in the service-side app registration rather than client-side app registration.
For an Microsoft Graph token, we are unable to configure it in the service side because the Microsoft Graph app registration is officially managed by Microsoft.
Configuring accessTokenAcceptedVersion in your client-side won't change the token version to 2. It is expected.
This feature is mainly used when you call you own AAD protected web API, rather than Microsoft official API.
UPDATE:
If you want to call you own API, you should create the service-side app registration by Protected web API: App registration and set accessTokenAcceptedVersion in it.
Here is the complete document for Scenario: A web app that calls web APIs.
I am retrieving an Azure AD access token using MSAL.js at the client and passing it as Authorization header to web api hosted in WCF API Management. But I get an error along with all the proper response as well my username and email
Cannot validate access token. IDX10501: Signature validation failed.
Key tried: 'System.IdentityModel.Tokens.X509AsymmetricSecurityKey
The API is a WCF service configured with a custom policy binding for OAuth with the metadataEndpoint or even the v2 version https://login.microsoftonline.com/{tenantid}/.well-known/openid-configuration .
I guess the Azure AD Access token that I have is not meant for validating authentication again.
My guess I might be either missing permissions on the App registration but I couldn't find an API permission for exact authentication/authorization.
I believe with new Azure AD , we cannot authenticate the earlier manner by just passing a token and need to use MSAL standard libraries.
Could someone shed some more light on this.
I used an ID Token and then it worked. You get 2 tokens when authenticated so the ID token seems to work.
I'm enabling OAuth2 for my Azure API Management instance. I click Add to add OAuth2, and it's asking me to enter name, and description of authorization service, so my thinking is I am creating an authorization service here.
Why is it asking me to provide client id, client secret, resource owner user, and resource owner password. I understand the concepts of OAuth2 and how these are used, but I am setting up API Management to handle OAuth2 authorization, so the job of the Authorization server will be to validate authorization codes and client secrets. The clients will have their own Client IDs and Client Secrets. Resource Owner should be an Azure AD identity with it's own user name and password.
Why, when I am setting up the authorization server for API Management is it asking me to enter Client ID and Client Secret as well as Resource Owner credentials. It doesn't make sense to me. Can someone explain?
So....what gives? Am I in the wrong screen because API Management
APIM can't be used as OAuth server. The only reason at the moment to configure OAuth/OIDC server in APIM is to make sure it's included into exported specification of an API and that developer portal has a convenient UI to let users obtain tokens, nothing else. That's why it's expected to provide client id and secret, because APIM is effectively a client.
Step 1 : Choose an OAuth provider such as Auth0
Step 2 : Configure various OAuth scenarios as API's in your OAuth provider (API is the term Auth0 uses, other providers might refer to them with other terms)
Step 3 : Create APIM OAuth 2 records, filling in the fields in your question (client id, client secret). Create a record for each API you have configured in your OAuth provider (in Step 2).
Step 4 : In the APIM edit the details of the various API's choosing the appropriate OAuth record you setup in Step 3. Here you are choosing the OAuth scenario for each of your APIs. Many APIs may use the same scenario, but obviously an individual APIM API entry can only link to 1 OAuth scenario
Thus you have configured various APIs in the APIM against various OAuth scenarios. Usually the details behind the OAuth setup are invisible to the API and are so setup and exposed only by their ClientID, secret and urls for token and authorise.
Auth0 has a good tutorial for seting up Azure APIM: HERE
apim should have it's own identity. Have you created an app registration for the instance? The credentials from the app reg on aad used will identify apim and allow validation of the token.
I have an Azure mobile service setup and have followed the examples online for authenticating. I call AuthenticationContext.AcquireToken and get back a token. Then I set the header using:
HttpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", AquireAccessToken());
However I am getting a 401 back and in the Azure logs I am getting "The 'Bearer' HTTP authentication scheme is not supported". What am I missing?
If you are using a service to call the mobile service why not use the Application key instead of a login process?
You can set a header on your request like so:
HttpClient.DefaultRequestHeaders.Add("X-ZUMO-APPLICATION", "<YOUR APP KEY>";
You can get your application key from the portal. When you are on the dashboard view click the button at the bottom of the window to "manage keys".
This works if you want to login as the service, but if you need to login on behalf of a user, then you'll need to go the authentication route. You'll also need to make sure the permissions on your various tables and APIs allow the application key level of access.
Alternately, you can use the X-ZUMO-MASTER header with your master key to get admin rights to the service.
Mobile Services does not support tokens being passed in the Authorization header. Instead, please consider using the POST method for the login endpoint. The Mobile Services SDK makes this available as an overload of the login method if desired.
Could you please comment on what examples you are following? Our standard "Get Started with Authentication" tutorial shows how to do login without handling an access token directly. We also have tutorials for using a provider SDK to obtain a token and pass it to the mobile service using the overloads mentioned above. For example, we have this tutorial for Microsoft Account and Azure Active Directory