I’m running into some problems getting our code to authenticate to Azure AD. I’ve configured an application and set up our code to request an authorization “code”. That much works, but when I try to exchange the “code” for an “access_token” I get caught in a variety of errors. First I get a “missing resource identified” error. I dug into the Manifest and pulled out a resource-id to pass but then I get a “missing client_secret” error.
But I’m not sure I’m going down the right path here. For one, I’m not sure what resources, if any, I need to access. Since we are just trying to authenticate I don’t think I need to actually request access to any other APIs do I? Maybe I do but I’m not sure which or what I would do with them.
Also, I found this blog post which seemed encouraging:
http://www.andrewconnell.com/blog/azure-ad-oauth2-openid-connect
He makes it look like I should be able request both the “code” and the OpenID Connect id_token in the initial authorization request. Which on glance seems to be all I would need to do. But when I try to append the “+id_token” to the “code” resource_type param as he suggests I get a “missing nonce” error. If I include a “nonce” parameter with a random string it goes through without errors and it hits my redirect_uri but I don’t get any data back in the response, and certainly not the profile information he indicates I should see in the blog post.
if you want to authenticate you definitely want to use OpenId Connect - OAuth2 is for authorizing your app to act as a client against a different resource, rather than getting a token for sign in purposes. I recommend taking a look at http://aka.ms/aaddev for overviews and quickstarts. In particular, see this for an explanation of the topology and this for a quickstart on how to do openid connect authentication.
Does adding 'response_mode=form_post' allow your app to receive both code and id_token?
Example sign-in request (GET)
https://login.microsoftonline.com/common/oauth2/authorize?response_type=code+id_token&response_mode=form_post&scope=openid&client_id=insert-client-id&nonce=insert-nonce&redirect_uri=insert-redirect-uri
Related
I am currently learning full stack dev, and have made a simple application with React on the front end, and set up a very simple REST api on my express web server that handles certain routes.
For example api/users returns a list of users from my database and returns responses as JSON data. api/blogs can return a list of blogs in JSON with a get request, or post a blog with a post request.
I have learned and been able to implement very basic user tokenization with JWT, and so only logged in users with a valid token can make a post of a blog for example. This is done by adding their token with bearer as a Authentication header in the request, which the server verifies. This makes sense to me, however I am very confused on how the backend works or if I am doing something critically wrong.
If I go to my main page for my application, and type api/blogs it opens up a page displaying JSON data. Anyone can basically view this from my application by going to api/endpoint
I am also assuming anyone from outside can use something like Postman to send a post request to my database assuming they have the token which they got since my token is saved in storage.
This is incredibly weird to me Is this just how these things work? Or am I failing to understand something crucial?
if I wanted to progress forward and learn more about this, where or what do I do?
You have described how users authenticate to your application (with a bearer token), but what steps does your application take before issuing such a token?
Does your application keep a database of users and their passwords?
If yes, can anyone sign up by inventing a user name and password?
Do you verify an email address before admitting a new user?
Or does your application rely on an external OpenID Connect service (for example, login with your Google or Facebook account)?
If yes, can anyone with a Google or Facebook account sign up for your application?
Or must an application admin (that is, you) put the user on an "allow-list"?
To summarize: Unless you take special precautions, anyone from outside can sign up to your application and subsequently use it.
So, this is kind of related to the question here: How to enable CORS in an Azure App Registration when used in an OAuth Authorization Flow with PKCE?
I want to implement OAuth 2 for our single page JavaScript applications written in ExtJS.
The server-side is written in .NET (4.6.2 currently) and has both JSON services used by the UI (implementing Ext.Direct) and SOAP services used for client integration.
We currently handle our own authentication which works quite similarly to the authorization code flow really. We login with a client id, username and password to get a token generation token (TGT), and then use this to request a short-lived product service token (PST). Requesting a PST extends the life of the TGT. When the TGT expires the user has to re-authenticate.
For the OAuth 2 route I obviously would like the user interface to direct people at the login page for Azure, the user to login there, with whatever MFA they may require, and then come back to the UI as a known user.
I'm not bothered where I go for the product service token, although I think it makes sense to go to Azure if possible, since ultimately we'd like to move everyone in that direction I suspect.
So, I have wrapped some of the code above in an ExtJS class, and managed to retrieve a valid authorization token. So far so good.
When I then attempt to request an access token I hit the same issue with CORS that the poster of that question did.
I just cannot see how anyone can be using the Authorization Code with PKCE flow with Azure at the moment, since your application will never be hosted on the same domain used for login surely?!
Anyway. I'm wondering about my options.
I'm wondering now if I can post the authorization code that gets passed back to the UI (with the PKCE code perhaps) up to the web services and get the web services to handle the communication with Azure for the access tokens.
Does that stand more chance of success, or am I just going to hit the same problem there?
Implicit Flow is not an option. None of our clients will accept that.
What other options are there?
Is there a purely server-side to Azure option that I should be using, and worry about the UI afterwards?
Struggling to see a way forward!
Would appreciate any insights you may have.
Cheers,
Westy
Okay, after days of banging my head against the stupidity of Azure's implementation I stumbled upon a little hidden nugget of information here: https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/lib/msal-browser#prerequisites
If you change the type of the redirectUri in the manifest from 'Web' to 'Spa' it gives me back an access token! We're in business!
It breaks the UI in Azure, but so be it.
I hope this helps someone else going through similar pain.
I'll also post on the linked thread :)
So I created an application in Azure AD a few days ago. When requesting authorization code, I am getting the following error back when I ask for both code and id_token (in response_type parameter):
AADSTS70007: 'query' is not a supported value of 'response_mode' when
requesting a token
Trace ID: xxxx-xxxx-xxxx-xxxx-xxxx
Correlation ID: xxxx-xxxx-xxxx-xxxx-xxxx
Timestamp: 2018-06-13 16:06:03Z
My request URL looks something like this:
https://login.microsoftonline.com/common/oauth2/authorize?resource=https%3A%2F%2Fmanagement.core.windows.net%2F&client_id=application-client-id&response_type=code+id_token&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob&response_mode=query&nonce=1528906255418&state=12345
However, I don't get any errors if I only ask for code and not id_token. So essentially, following URL works:
https://login.microsoftonline.com/common/oauth2/authorize?resource=https%3A%2F%2Fmanagement.core.windows.net%2F&client_id=application-client-id&response_type=code&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob&response_mode=query&nonce=1528906255418&state=12345
What is even more interesting is that if I use a client id of an application created a few months ago, the code works perfectly fine and Azure AD returns me both code and id_token.
I did find one similar problem here: https://sharepoint.stackexchange.com/questions/242669/aadsts70007-query-is-not-a-supported-value-of-response-mode-when-requesting but there was no answer provided for that question.
I'm curious to know:
Why Azure AD does not throw any error for older application but for newer application? Has anything changed at the Azure AD level recently that will cause this problem? And that too for only newer applications.
Is there a way to prevent this error from happening? I would very much like to use query as response_mode instead of form_post.
Two different authorization flows:
If you want to use code + id_token in the response_type,you should be using OIDC Hybrid Flow.
However, if you just use codein the response_type, you should be using Authorization Code flow.
So, These two kinds of requests are different OIDC Authentication flow due to their different response_types.
Meanwhile, two different response_modes:
For form_post, form_post executes a POST containing the code to your redirect URI.When the Authorization Response is intended to be used only once, you should use form_post in reponse_mode. You can also see the details about form_post in this documentation.
For query, In this mode, Authorization Response parameters are encoded in the query string added to the redirect_uri when redirecting back to the Client. For more details about query in response_mode, you can refer to this documentation.
So, you may be more clear about the different response_mode for different Authorization flows.
For Authorization code flow, you can use query or form_post, For Hybird flow, you can use form_post or fragment. For web applications, we recommend using response_mode=form_post, to ensure the most secure transfer of tokens to your application. (the Microsoft OpenId Connect middleware only supports hybrid + form_post)
Why Azure AD does not throw any error for older application but for
newer application? Has anything changed at the Azure AD level recently
that will cause this problem? And that too for only newer
applications.
I'm not 100% sure, but AAD shouldn't change anything about its authorization/authentication level. Maybe you used different types of App or authentication flow.
Is there a way to prevent this error from happening? I would very much
like to use query as response_mode instead of form_post.
Since the reason is caused by OIDC framework, I think you cannot use query for hybird flow request.You'd better use form_post
in this flow if your app is a web app.
Additional, Azure portal is using this flow actually, but it may be a little different from what we can use. But you can see how the authentication/authorization works by catching its HTTP traffic via Fiddler. With this flow, you've to enable your App to allow implicit flow.
You can also see this sample for Authenticate using Azure AD and OpenID Connect Hybrid flow in this documentaion.
Adding an answer for the sake of completeness. Wayne's answer helped immensely!
So, instead of using response_type=query, I ended up using response_type=fragment and my new request URL now looks like the following:
https://login.microsoftonline.com/common/oauth2/authorize?resource=https%3A%2F%2Fmanagement.core.windows.net%2F&client_id=application-client-id&response_type=code+id_token&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob&response_mode=fragment&nonce=1528906255418&state=12345
And I was able to get both code and id_token back:
urn:ietf:wg:oauth:2.0:oob#code=code&id_token=id_token&state=12345&session_state=c6989d04-48ff-40cd-86ac-0cd2670ee168
Removed urn:ietf:wg:oauth:2.0:oob# and then parsed the remaining string to get both code and id_token values in the application.
Problem: I'm trying to use Postman to get an valid Azure AD access token that I can then use to pass on a request to an Azure Function protected by Azure Active Directory (Easy Auth).
I've read / viewed numerous explanations on how to do this. CGillum's entire blog for example. Some of the best ones (that don't quite work for me) are:
https://blogs.msdn.microsoft.com/devkeydet/2016/03/22/using-postman-with-azure-ad/
https://youtu.be/ujzrq8Fg9Gc
Even a similar question that I posted: Authentication for Azure Functions
I've verified that my ClientID, secret, and callback are all correct. I've ensured I have (what I think are) the correct permissions to the app I registered in my directory. I've got back a valid Bearer tokens in both of the first two examples above. No matter what though, when I pass this token back in the Authorization header I get a message that states "You do not have permission to view this directory or page."
My hope at this point is that someone reading this will point out the obvious thing that I missed.
Thanks in advance
We could use the following way to get the easy auth token easily.
1.Vist the following url from browser and input your creditial.
https://{yourfunctionAppName}.azurewebsites.net/.auth/login/aad
2.After that we could get the easy auth token after decode the url.
3.Test it with Postman
During the recent Microsoft Cloud roadshow in London, something that came out of one of the talks on App Service was using AAD B2C for authentication.
It is possible currently to add Azure AD as an authentication for an API App:
Calling this API app from a browser based web app with no authorization header results in a 302 redirect immediately followed by a 401 response.
It was mentioned at the cloud event that it would be possible to call an API app anonymously from a web app, and have the azure App service handle the redirection to the AAD login page, get the token on successful login and then pass the call on to the API app and return the data.
However, I am struggling to see how this can be achieved without any responsibility on the calling web app to handle the redirect. Normally you would handle a 401 response from an API by obtaining a bearer token via AAD on the client side and sending it through as the authorisation header with the api request.
I have been through numerous examples on the Azure site and others and all of them are handling the logon/obtaining the token in the client web app.
Is this even possible?
UPDATE I just realized (as pointed out by #Darrel-Miller that you don't really want to allow the user to put the credentials in.
The only thing that is still unclear to me, is where do you want to provide the credentials for AAD?, What is it exactly what you would like to accomplish.
Even more, why would you use AAD if there no user interaction at all.
If all that you want is a secure connection you can just use the standard application key for the web api without enabling AAD. And its as pretty straight forward to just add the MS_ApplicationKey to your header and you are good to go.
As you described in your comment you have a webclient that tries to do the requests and gets the 302, that is why my original answer wast that you would use ADAL. But now that I get deeper into what you want probably what you want to use is KurveJS :
https://github.com/MicrosoftDX/kurvejs
And it has the AAD app model v2 with Active Directoy B2C.
This makes it easy to add third party identity providers such as Facebook and signup/signin/profile edit experiences using AD B2C policies
You can read more about it here:
https://github.com/MicrosoftDX/kurvejs/blob/master/docs/B2C/intro.md
Do you mean this??
https://msdn.microsoft.com/en-us/magazine/dn463788.aspx
Just use ADAL nuget package to handle the call...
You can read this from the post:
As soon as the execution hits the call to AcquireToken, you’ll get the authentication dialog shown in Figure 8. ADAL takes care of contacting the right endpoint and rendering the authentication experience provided by the server in a pop-up dialog without requiring you to write any UI code.
I hope this works for you!