I've been looking at examples and documentation for using token/claims based authentication in .net applications using wif or thinktecture identitymodel.
One example was: Token based authentication
But I cant seem to find information regarding how tokens 'should' be used.
Given the .net console app scenario:
How are or how do you persist the tokens?
Where should they be stored?
Should they be stored?
Or are you sposed to request a new token everytime the user loads the console app?
Naively I assumed, the user would load the app, request a token, STS would issue token (if their username maps against a username in the provider etc.), token would be sent to user, app would deserialize token, extract claims and use claims accordingly.
I'd like to understand how tokens should be persisted, then I assumed you should check for a token upon app loading, check if token hasnt expired etc.
View from anyone with token/claims based authentication in .net/windows apps (winforms, console) would be great hear.
Related
There are several .Net sample codes that using oauth2 to signin Xero, but all of them is working with browser (most of the sample code for C# is for ASP.NET MVC).
I am going to develop a desktop application using Xero Api but Xero official tutorial said that mobile or desktop application should use PKCE flow instead of using ClientID/Secret scheme.
And in this PKCE flow, user should interact with browser to get Authorization code.
I want to know if there is any way to signin without user interaction.
Xero api signin was just migrated to use OAuth2.0 and it should interact with browser at least once.
Once you get refresh_token using offline_access scope, you will use this token to get access token.
Unfortunately they don't support custom url scheme.
Hope this will be helpful for you.
I had the same problem, and there were no examples of how to do this.
As mentioned you need to create a refresh token (which does mean you have to open a browser at some point), but after that you can keep refreshing the token to get new access tokens. A refresh token can be used only once so you must store the new refresh token after each use. You must make sure to only allow one program/thread to refreshes the token at a time. Refresh tokens will expire after 60 days if they're not refreshed.
I created a worked example on github to show how to do this.
Since I produced this Xero have sent me a link to a new desktop based program which replaces their XOAuth console program for generating the refresh token.
Now that .Net 5 is available you could look at embedding Edge into the application for when you have to log into Xero
I am working on a .net MVC and web API project and using active directory to authenticate users to API, on authentication, a code is being returned from AD and I have to exchange the code to obtain a token and use that token to call the API, the question is why is the code returned and why do I have to exchange it for the token? can I directly obtain a token?
This is all because of security reasons.
OAuth 2.0 wanted to meet these two criteria:
All developers will not have an SSL enabled server and you should allow them to use non-HTTPS redirect URI
You don't want hackers to be able to steal access/refresh tokens by intercepting requests.
Since the Authorization Code grant has the extra step of exchanging the authorization code for the access token, it provides an additional layer of security not present in the Implicit grant type.
According to Nate Barbettini we want the extra step of exchanging the authentication code for the access token, because the authentication code can be used in the front channel (less secure), and the access token can be used in the back channel (more secure).
Thus, the security benefit is that the access token isn't exposed to the browser, and thus cannot be intercepted/grabbed from a browser. We trust the web server more, which communicates via back channels. The access token, which is secret, can then remain on the web server, and not be exposed to the browser (i.e. front channels).
For more information, watch this fantastic video:
OAuth 2.0 and OpenID Connect (in plain English) https://youtu.be/996OiexHze0?t=26m30s (Start 26 mins)
Your question isn't really specific to Azure AD, and is more about the OAuth flow and why it is used.
The flow seems a bit complex, and well, it is, but there are reasons for all the things it does.
I encourage you to use authorization code flow instead of other approaches.
It has many advantages:
Your app will never see the user's password
The user cannot see your app's client secret
The user cannot see your app's access tokens (and neither can a man-in-the-middle attacker)
You get a refresh token that you can use to get new tokens whenever needed (you do need to specify the offline_access scope for this though)
The user can go through multi-factor authentication, federated authentication with ADFS etc., and your app doesn't need to care about that
Alternative flows and their downsides:
Implicit flow
Gives you a token directly without the code exchange
There is no refresh token
Mainly used in Single Page Apps, where refresh is done using a hidden iframe, but that depends on the user's session remaining active
If you use this outside a SPA, you can't really refresh the token, requiring the user to login again every hour
User can see and take your app's access tokens
Client credentials flow
Instead of accessing the API as a user, you access it as the app itself
Some APIs do not support this approach and require you to make calls on behalf of a user
This doesn't allow you to authenticate a user
Application permissions are needed to use this flow, which usually give very broad access to the entire organization
The upside of this flow is that it is very simple
Resource Owner Password Credentials flow
Do not use this flow
HTTP request to token endpoint with app + user credentials
Exposes user password to your app (!)
Does not work if user has MFA, expired password etc.
I am currently building an API which requires OAuth2, but cannot find a library to use that will handle the single sign on in a native mobile app via RESTful API only. Most I've found only have a web popup, which has been vetoed for this project. B2C, which is currently functioning, is not capable of using ROPG. Is there a way to easily set this up with another library using C#.NET and Azure?
UPDATE:
Attempting to use B2C per Fei Xue answer below, we got to the point of getting an access token from Microsoft Graph.
In the body of the POST, we did the following:
resource=https%3A%2F%2FGraph.windows.net&client_id=[B2C Settings -
Applications -
AppId]&grant_type=password&username=rob%40[tenant].onmicrosoft.com&password=[password]&client_secret=[B2C Settings - Applications - App Key - client_secret]
Our error with the namespace was due to the usernames we were trying. This is a B2C tenant using email as the username and that was the reason for the namespace error. The only way we got past that error was to create a B2C user with the email address ending in the tenant, like so:
rob#[tenant].onmicrosoft.com
We are getting an access token now, but that token does not authenticate with our azure app service api app, which was the original goal.
What we are trying to accomplish is to send the username and password that is valid for a B2C signin and get an IdToken or Access Token that is valid for the api app. The api app connects to B2C via App Service Authentication settings configured for AAD with the Client ID and secret setup from the B2C Settings Application.
UPDATE:
Attempting to pass through the graph.windows.net token for authentication in our Azure web api, we added in the https://Graph.windows.net allowed token audience in our App Service – Authentication – Active Directory Authentication configuration.
However, passing the graph access token in the Bearer header to the API still results in
“Authorization has been denied for this request”.
Found out that if we make the Issuer Url blank like in the example below, it now accepts the Graph token!
However, this causes issues when trying to hit
https://[our_web_app].azurewebsites.net/.auth/login/aad
It goes to the common Microsoft login now. Previously it directed to our B2C sign up in policy because the Issuer Url was set to:
https://login.microsoftonline.com/[tenantname].onmicrosoft.com/v2.0/.well-known/openid-configuration?p=[B2C_SignUpIn_Policy]
In fact, if we also pull up the policy from within our app (which was working before removing the Issuer Url) to the sign in policy, we can sign in, but that returned Access Token now always comes back as Unauthorized in the web API calls.
Should the Issuer Url be left blank?
Also, since making the Issuer Url blank, the server takes much longer to respond to API calls when we send a request using a Graph access token in the Header Authorization Bearer. It went from taking about 1-2 seconds (using a valid B2C access token obtained from MSAL or the web login above) to taking about 10-15 seconds to respond that it is an authenticated request. That kind of speed is a show stopper for us. Does validating a graph call in this manner normally take this long?
The feature is now available in preview and works pretty well:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/configure-ropc
Important note: The POST url mentioned in the documentation is wrong.
https://login.microsoftonline.com/{{Aad_Tenant}}/b2c_1_ropc_auth/oauth2/v2.0/
Must be:
https://login.microsoftonline.com/{{Aad_Tenant}}/oauth2/v2.0/token?p=b2c_1_ropc_auth
The calling application must have native client enabled, otherwise you will get this error:
AADB2C90224: Resource owner flow has not been enabled for the application.
The Azure AD B2C has already support the Resource Owner Password Grant flow, you can send the HTTP request like below to using this flow:
POST: https://login.microsoftonline.com/{tenant}/oauth2/token
resource=https%3A%2F%2FGraph.windows.net&client_id={client_id}&grant_type=password&username={userName}&password={password}&client_secret={secret}
Note: this flow only work for the local accounts as social identity providers(Facebook, Google, etc) don't support this.
Update
The token above is acquiring the token for https://graph.windows.net. To pass through the authentication of web API which protect by Azure AD, we need to specify this as the ALLOWED TOKEN AUDIENCES like figure below:
Update to the answer from #AlexAIT.
The URL in the documentation now works for AD B2C.
https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/B2C_1A_ROPC_Auth/oauth2/v2.0/token
https://learn.microsoft.com/en-us/azure/active-directory-b2c/add-ropc-policy?tabs=app-reg-ga&pivots=b2c-user-flow#test-the-ropc-flow
If you get the error:
AADB2C90224: Resource owner flow has not been enabled for the
application
Navigate to application -> Authentication and select Enable the following mobile and desktop flows:.
Wait a few minutes and then it will start to work.
Github thread:
https://github.com/MicrosoftDocs/azure-docs/issues/50330
I work with Rob, and we did finally get the call to work with
https://login.microsoftonline.com/[tenant_ending_in_onmicrosoft.com]/oauth2/token
In the body of the POST, we did the following:
resource=https%3A%2F%2FGraph.windows.net&client_id=[B2C Settings - Applications - AppId]&grant_type=password&username=rob%40[tenant].onmicrosoft.com&password=[password]&client_secret=[B2C Settings - Applications - App Key - client_secret]
Our error with the namespace was due to the usernames we were trying. This is a B2C tenant using email as the username and that was the reason for the namespace error. The only way we got past that error was to create a B2C user with the email address ending in the tenant, like so:
rob#[tenant].onmicrosoft.com.
We are getting an access token now, but that token does not authenticate with our azure app service api app, which was the original goal. What we are trying to accomplish is to send the username and password that is valid for a B2C signin and get an IdToken or Access Token that is valid for the api app. The api app connects to B2C via App Service Authentication settings configured for AAD with the Client ID and secret setup from the B2C Settings Application.
UPDATE:
If I add ?p=[B2C SignUpIn Policy] to the POST, then we get the following error:
AADB2C90224: Resource owner flow has not been enabled for the
application.
I have an ASP.NET Application created using the Visual Studio 2013 project template. For security, I chose Azure Active Directory. I have all of the login working, but I'd like to start using the Graph API to manage users in my application. I have created an Application Key to use with Azure AD, but I'm not quite sure how to go about making graph calls.
I've studied the code at https://github.com/AzureADSamples/WebApp-GraphAPI-DotNet, but using the graph API in that way requires a token.
Is there a way to get a token from my ASP.NET application after it has successfully logged into AD that I can use to call the graph API? Maybe by adding a method to Global.asax?
Is there another way to call the graph API from an ASP.NET application created with this project template?
Indeed, you do need an OAuth token using which your web application can access the Graph API, on behalf of the logged in user. If you're using .Net, you are looking at the correct sample - OpenID Connect is the recommended protocol to sign-in the user and get an authorization code to access Graph API: https://github.com/AzureADSamples/WebApp-GraphAPI-DotNet.
The OpenIDConnect (SSO + Auth Code Grant flow) begins when the user clicks Sign-in link. See the _LoginPartial view (https://github.com/AzureADSamples/WebApp-GraphAPI-DotNet/blob/master/WebAppGraphAPI/Views/Shared/_LoginPartial.cshtml) and the SignIn Action in the AccountController.
The main magic happens in Startup.Auth.cs (https://github.com/AzureADSamples/WebApp-GraphAPI-DotNet/blob/master/WebAppGraphAPI/App_Start/Startup.Auth.cs): It configures a delegate on the event AccessCodeReceived to redeem the OAuth Access Code for a Refresh Token and Access Token for the resource (Graph API) and puts the tokens in the token cache.
See AuthUtils class (https://github.com/AzureADSamples/WebApp-GraphAPI-DotNet/blob/master/WebAppGraphAPI/Utils/AuthUtils.cs): The GetAuthToken method first tries to retrieve an access token from the token cache. If the access token and refresh tokens have expired, it re-authenticates the user to populate the token cache with fresh refresh token.
See TokenCacheUtils class (https://github.com/AzureADSamples/WebApp-GraphAPI-DotNet/blob/master/WebAppGraphAPI/Utils/TokenCacheUtils.cs): It calls the AAD token endpoint to get an Access token for the resource (Graph API in your case), using the Refresh token using the code
Hope this helps
I am totally lost finding the right API to create a sign up process like Foursquare. I am attaching a document of what I am trying to do. I have already tried OAuth, JavascriptSDK, Facebook.NET API from Codeplex and FacebookToolkit.NET from Microsoft. Nothing looks what I actually need. I think some one experienced can lean me towards where I should go straight.
https://docs.google.com/fileview?id=0B6mlBkccI34zNDNmMGMyNTYtMDY2NS00NmEwLTlkMjQtZjA5NmVmZDMzYzlj&hl=en&authkey=CNPH9LEL
Note: I am trying to achieve this via ASP.NET with C#.
Facebook Graph Api is the best.The url is http://developers.facebook.com/docs/api
The Graph API uses OAuth 2.0 for authorization. Check out the authentication guide for the details of Facebook's OAuth 2.0 implementation.
OAuth 2.0 is a simpler version of OAuth that leverages SSL for API communication instead of relying on complex URL signature schemes and token exchanges. At a high level, using OAuth 2.0 entails getting an access token for a Facebook user via a redirect to Facebook. After you obtain the access token for a user, you can perform authorized requests on behalf of that user by including the access token in your Graph API requests:
https://graph.facebook.com/220439?access_token=...
Check out the PHP example code or the Python example code on GitHub to see a complete example of obtaining an access token for the current user. The steps to obtain an access token are:
Register your application to get an app ID and secret. Your Facebook app ID is your client_id and your Facebook application secret is your client_secret.
Redirect the user to https://graph.facebook.com/oauth/authorize with your client_id and the redirect_uri. The redirect_uri parameter needs to begin with your app's URL. For instance, if your URL is http://www.example.com then your redirect URI could be http://www.example.com/oauth_redirect.
https://graph.facebook.com/oauth/authorize?
client_id=...&
redirect_uri=http://www.example.com/oauth_redirect
After the user authorizes your application, we redirect the user back to the redirect URI you specified with a verification string in the argument code, which can be exchanged for an oauth access token. Exchange it for an access token by fetching https://graph.facebook.com/oauth/access_token. Pass the exact same redirect_uri as in the previous step:
https://graph.facebook.com/oauth/access_token?
client_id=...&
redirect_uri=http://www.example.com/oauth_redirect&
client_secret=...&
code=...
Use the access token returned by the request above to make requests on behalf of the user:
https://graph.facebook.com/me?access_token=...
You are looking for the Facebook Connect API.
More info for the single login process can be found here
You could also leverage OpenID
Your document notes the Yelp signup process, which is very low friction and allows the user's information to be available to the website without having to go through Facebook's authentication process.
Yelp, Microsoft Docs, and Pandora are using a feature of Facebook called Instant Personalization. Instant Personalization is not available to developers as of yet and is only available to those three partners.
That being said, you likely would need to use the Facebook Login Button to allow the user to grant you access to their information (including their friends list).
As far as the process of getting a list of friends, use the graph call "me/friends"
I manage FaceSharp, a .NET open source project to help people get started with Facebook Development and will be adding functionality similar to what you are looking to do in the future, perhaps some of that code will help you in your efforts. It's under the MIT license, so take whatever you want.