I don't need Microsoft Login screen.
If I am already having username and password with me ,
can't I just pass them using Http client and get the authentication token.
Is it possible , please suggest.
The Azure AD supports various flow about OAuth 2.0. To acquire the access token with username and password directly, we can interact with resource owner password credential flow. However this scenario should be used carefully since it may leak the password. You can refer this flow about specification from rfc6749#page-37.
And to implement this flow using C#, you can refer this blog.
The short answer is, it is possible but not recommended (See comments from Philippe below).
The ability to get a token when you have a user name and password is extremely limited.
You might be able to do this in rare scenarios when your device is not able to prompt the AAD Auth page, or in cases when it is a native app/automation tests and etc.
Please see this post for the limitations and workarounds:
http://www.cloudidentity.com/blog/2014/07/08/using-adal-net-to-authenticate-users-via-usernamepassword/
Also look at this answer from me here, where I made it to work for our automation tests, but Vibronet has comments that, this solution will stop working, but not sure it has happened yet or not.
How to acquire a user based token from Azure Graph API
Related
I read a lot about OAuth 2.0 and OpenId Connect and in theory I understand both concepts now.
But if I go into practice, some things are still confusing for me and I hope you can enlighten me in some way...
First thing is, that in all code samples how to secure a .net core API in an AAD-environment I find lines like this in the configure-section:
app.UseAuthentication()
and lines like this in the ConfigureServices section:
services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
.AddJwtBearer(options =>
{
options.Authority = "https://login.microsoftonline.com/xxxxxxxx";
options.Audience = "xxxx-xxx-xxx-xxx-xxxx";
});
However, to access my API I am not using an ID token, but an access token what is Authorization, not "Authentication" like in the code samples.
This works - but I do not understand it 100%.
So my first question is:
Is the access token also "authenticating" in some way?
The second thing:
I read that access tokens have no standardized format. They can be JWT or not, can have an audience or not etc. For this reason you could even put user information in the token like microsoft does. The access tokens contain claims like a "family name" or "given name" etc.
Id tokens in contrast have a standardized format to ensure that authentication is done in the same way by everyone.
If people are accessing my apis with an access token, I can read their name or e-mail address with "user.identity.name" for example. This value I can use to store the information who edited something or who inserted something.
So I am fetching information about the user with access tokens!
So my second question is:
Am I doing the right thing here? Or should this be done in another way.
and:
Should access tokens ever contain information about the user?
Is the access token also "authenticating" in some way?
Yes.
Your API is validating the access token when it receives it.
This is the authentication part, when your API verifies that the token signature is valid, came from the Azure AD tenant that you trust, that it is meant for your API and that it has not expired.
The authorization is when you check what permissions the token contains.
Your API can define different permissions that are given to client applications, allowing them different levels of access.
A valid token can pass authentication, but it might not pass authorization if it lacks the necessary permissions.
Am I doing the right thing here? Or should this be done in another way.
Fundamentally your are doing the correct thing.
The token tells you who the user is that is using the client application, and if you need to know who it was who did something, that's the info you use.
However, if you really want to connect an action to a user, I suggest you use their object identifier / object id / oid instead of their name / username as those can change.
Unless you just want their display name.
Should access tokens ever contain information about the user?
In the context of Azure AD, an access token will always contain info about the user if a client application is accessing an API on behalf of a user.
This includes authentication flows like authorization code, device code, implicit, and on-behalf-of.
They all use delegated permissions aka scopes to call APIs on behalf of the user.
Thus the token contains info about the calling app and the user.
If an app acquires an access token using the client credentials flow where a user is not involved, there will be no user info in the token.
In this case, application permissions are used instead of delegated permissions in Azure AD.
An application acts as itself, not on behalf of any user.
If your API supports both of these scenarios, sometimes the tokens contain user info and sometimes not.
The part about token formats is basically correct from a specification standpoint.
OAuth doesn't define a strict format for access tokens, while OpenID Connect does define one for ID tokens.
Using an access token to call your API is definitely correct.
The ID token is only meant for the app that initiated the user authentication, not for any APIs that it calls.
That's what access tokens are for.
if you check here: https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens
in the newer access tokens, by default it follows the standard of not having any personal information about the user. which is what the standards suggest, Access tokens should not contain much or any information About the user. rather just information for authorization (things that user can access).
However you can always add the optional claims (and azure lets you do it) for personal info, but best practice suggests you shouldn't.
in terms of the addauthentication: Authentication is basically proving who you say you are. addauthentication(), basically calls microsoft azure ad to perform this task, saying hey aad please ask this person who he is, azure then checks and says ya this is a real person, but i won't tell you anything about him other than an id, and they have access to your api/application. So from your snippit, it's fine.
at this point, your serverside shouldn't have any personal information about the user, just that they have access and what scopes/roles. If it wants info about the user, it should then take that authorization (access token) and request it from whatever endpoint that token has access to (graph)
here's a great read about it: https://auth0.com/blog/why-should-use-accesstokens-to-secure-an-api/
Hopefully this helped clarify somewhat, and not add more confusion to the issue.
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 :)
I am trying to create workflow using Microsoft Flow. Some of my steps are executing HTTP Requests using Microsoft Graph API. Problem I am encountering is that some API do not support Application Permission type, but rather Delegated. I am attempting to Create plan in Microsoft Planner (see this link). In this scenario I have created service account that will execute specific workflow and on the Azure AD application side I have granted permissions on behalf of user as administrator.
Because I have to execute certain HTTP Requests as "user" I am attempting to retrieve user authorization token there are two steps here:
Retrieve Authorization code
Retrieve Token based on authorization code
I cannot pass Step 1. I am following this documentation: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow and every time I attempt to execute following HTTP request:
GET https://login.microsoftonline.com/{my-tenant-id}/oauth2/v2.0/authorize?
client_id={my-client-id}
&response_type=code
&redirect_uri=https%3A%2F%2Flogin.microsoftonline.com%2Fcommon%2Foauth2%2Fnativeclient
&response_mode=query
&scope=Group.ReadWrite.All
I am using basic authentication by passing username and password. But I am getting response that "We can't sign you in, your browser is currently set to block cookies". Well there is no browser it is service account. Am I missing something or what I am trying to achieve is not possible and I have to have web application? Microsoft made connectors that use Planner API, but they made everything but connector to make plan in planner...
EDIT:
I am aware that issue is similar to this topic here, but answer in this topic says to use "App authorization" which is specifically pointed out by Microsoft in their documentation that in this scenario you cannot. I am aware of that I need actual user permissions as only type of permission allowed is
Delegated (work or school account)
this is why particular topic does not answer my question since that answer is pointing out to Application permission that is not supported in this scenario.
I think you're running into an issue because Authorization code grant flow is meant to work with user interaction, i.e. user gets redirected to login page to enter credentials interactively. You can read more about it in this related SO Post OAuth2 - Authorize with no user interaction (it's not specific to Azure AD but about OAuth 2.0 Authorization Code Grant flow in general.
Alternatives
Client Credentials Grant Flow
This would have been ideal and the best choice for any background/daemon process, but it will work with application permissions. Unfortunately the API you're trying to use only works with Delegated permissions as you have mentioned, so this grant won't work.
Resource Owner Password Grant Flow (this could work but violates security best practices and has functional issues)
ROPC works directly with user credentials (i.e. your code has direct access to username as well as password, which isn't a good practice by any means), and it doesn't require explicit interaction. Even though this could work out, please know that this grant violates many security best practices and it has functional limitations too (like doesn't work with Multi Factor Authentication, or with Personal accounts).
See this related SO Post where I have covered these in a little more detail. Normally I would refrain from mentioning this grant, but I don't see any other grant working in your case and that's the only reason to include it.
Sample request
// Line breaks and spaces are for legibility only.
POST {tenant}/oauth2/v2.0/token
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&scope=user.read%20openid%20profile%20offline_access
&username=MyUsername#myTenant.com
&password=SuperS3cret
&grant_type=password
Using Refresh Token (could work but it's also fragile and more like a workaround)
In this approach you could acquire a refresh token using service account first. You will need to do this separate from general working of the application, say as part of initial setup and with user interaction.
Then going ahead you can acquire token based on this refresh token. Refresh tokens can get revoked or expire. So you need to be aware of how long is refresh token valid for and events where it could become invalid. An event like password change could also make existing refresh token invalid. Also, you will need to secure the refresh tokens like a sensitive information (almost like a password itself)
So AFAIK, I'm only suggesting a couple of bad options, i.e. 2 and 3. Unfortunately API not supporting Application permissions takes out the good option.
One of the steps to authorize our application to access our DocuSign account requires a human to navigate to the oauth service (https://account-d.docusign.com/oauth/auth?response_type=code&scope=signature%20impersonation&client_id=...) then login to the account, and grant it access.
I've seen some references throughout the developer portal about this being something that will need done multiple times, and I've also seen it written on the same site that it only needs to be done once (the site is actually fraught with contradicting information).
Does anyone know if this step will need to be done more than once? It makes sense to me that it should NOT.
Much appreciated!
Chris
You are referring to https://docs.docusign.com/esign/guide/authentication/oa2_auth_code.html and it is a correct place for documentation for DocuSign. Now with above flow, you get two types of tokens i.e AccessToken and Refresh Token. If Access Token expires then you can use refresh token to get new set of access and refresh token and it does not need any consent from the user or a human action, it can be done using DocuSign OAUTH API from backend. But if the response to the refresh operation is an error, or if the new access token’s expires_in value is less than your threshold, you will need to repeat the initial authentication flow. So you need to do proper exception/error handling before taking user back to the consent/OAuth login page.
I am developing an app using node.js which will also have an mobile client. I am looking to make the authentication using OAuth 2.0. Is there any good module which allows me to have OAuth 2.0 authentication server?
I looked at a subsidiary module of Passport "OAuth2orize". I found it quite good enough, but the real problem was understanding how it will work for my own app (the example and docs specify about third party authorisation).
Basically what I want is that the client logs in with client id, user's username, user's password and there by I hand him a token after verifying the above 3 things. But the problem with Oauth2orize is that there there are redirect URI and all which is confusing me a lot.
Please help me know as to how can i achieve this using Oauth2rize or any other really good module. Or If its easy enough I can also roll my own, but will that be a good idea regarding security ??
What you are looking for is the Resource Owner Password Credentials flow. As you've seen, the examples for oauth2 do not include functionality that supports this flow. In fact the examples only cover the Authorization Code flow.
It should end up being fairly easy to implement. All you need to do is accept a request that contains the information you are looking for (and authorize it) and create a token in your token database and return it. As long as you use the same token database that the rest of oauth2orize is using, it should work just fine. See: Passing Trusted Client Information with oAuth2orize for the "Resource Owner Password Flow" where that is exactly what is suggested.
Correction:
The all-grants example of oauth2orize supports the Implicit flow as well as Authorization Code flow.