This stack is shaping up to be perfect for our use case:
Azure Mobile App
Azure AD
C# backend (using GetAppServiceIdentityAsync<AzureActiveDirectoryCredentials>() to authorize users to API endpoints based on security group membership)
Cordova client
The missing piece of the puzzle for me is the ability to silently obtain a refresh token. Can the Token Store take care of this for me? Or is there a supported method of doing this either with the Cordova plugin, or in the C# backend?
I mean, the inappbrowser caches credentials, so it's not like the users have to type a password again, but still, the window pops up and it would look a bit more polished if it was silent.
Thank you.
This is currently a little more tricky for Azure AD compared to the other providers. As a starter, I recommend you check out this blog post: http://cgillum.tech/2016/03/25/app-service-auth-aad-graph-api/
It describes how to set up your mobile app backend to allow it to access the graph API on behalf of the user. Specifically, the following steps are required:
Set clientSecret (a string property) to the key value that was
generated in the Azure AD portal.
Set additionalLoginParams to the
following: (This is a JSON array value)
["response_type=code id_token", "resource=https://graph.windows.net"]
I assume this might be useful for your app anyways since you're checking security group memberships? If you'd rather not do that, then you can remove the "resource=https://graph.windows.net" parameter.
In any case, as a side effect of following these instructions, you will start receiving refresh tokens for each logged-in user, which you can use to support silent token refresh in your Cordova client.
Related
I want to authenticate users with Azure Active Directory (AD) in a mobile app that calls its own REST API and possibly, make it simple.
Looks like the documented way (here or here) to do so is to
register the API app with AD, expose some scope(s) as delegated permissions
register the mobile app, add these scopes as API permissions to this app
do authorization decisions in the API app based on these scopes
Question:
Now, since I feel the front-end and back-end parts of my app should belong into the same "black box" plus there are no fine-granular user roles within the app that would justify usage of multiple scopes or require the user to consent to using them, I'm wondering whether there is a recommended (and secure) way to go with just one app registration instead of two?
What I tried:
When using Okta in a similar scenario, I only had one app (clientId) and the back-end configuration pretty much validated the JWT token issuer, domain and a default audience string (in my understanding). I tried inspecting tokens from AD acquired via the authorization code flow for usual scopes (openid profile) to see what their audience was and if this could be reproduced - this is what I've got:
the well known GUID of Microsoft Graph (for the access token) - this one doesn't feel "correct" to validate, as pretty much any AD user could present an access token for MS Graph and only assigned users should be able to use my app
client ID of the app (for the ID token) - but the docs says these should not be used for authorization, so not sure if it's a great idea to pass them as Bearer tokens to the API
The standard thing in OAuth technologies is to only register a client for your mobile app. Azure has some vendor specific behaviour when it comes to APIs, related to the resource indicators spec. When there is no API registration, your mobile app will receive JWT access tokens with a nonce field in the JWT header. These are intended to be sent to Graph, and will fail validation if you ever try to validate them in your own APIs.
If like me you want to stay close to standards, one option is to add a single logical app registration, to represent your set of APIs. You might design an audience of api.mycompany.com, though Azure will give you a technical value like cb398b43-96e8-48e6-8e8e-b168d5816c0e. You can then expose scopes, and use them in client apps. This is fairly easy to manage. Some info in my blog post from a couple of years back might help clarify this.
Now, since I feel the front-end and back-end parts of my app should belong into the same "black box" plus there are no fine-granular user roles within the app that would justify usage of multiple scopes or require the user to consent to using them, I'm wondering whether there is a recommended (and secure) way to go with just one app registration instead of two?
You can create just one app registration; in fact the newer app registration model was designed to do that.
In the case where an API is used only by the app itself, I would register a single scope, something like MobileApp.Access.
Your API should verify the presence of this scope to prevent unauthorized applications from calling it.
In addition to verifying the scope, you will need to verify user permissions.
And filter the data based on their identity, depending on your use case.
Your question seems to suggest that you might be mixing scopes and user roles.
Scopes are permissions given to an application.
Also called delegated permissions; they allow an app to do some actions on behalf of the signed in user.
i've a nodejs API.I need to develop a fucntionnality that based on a key search a user in azure active directory.
Someone can help me or indicate me some tutos about that.
Thanks
Preface
It'll depend a bit on if you want this to be entirely service-side without user interaction or if you want to run this in the context of the user.
This answer assumes the latter. The primary benefit of this approach is it will run the search based off the user permissions required (which may be less than enabling your app to do this as a service e.g. may not require admin consent). In general, all docs can be found at Azure AD Developer Docs.
Steps / Apps you need to build
You'll want to do the following things:
Sign in the end user to your client app (e.g. here's a SPA sample).
Have this client app request tokens to your Node Web API (e.g. here's a Node Web API that accepts tokens.
Then you'll want to check out the On-behalf-of protocol. This will allow you to exchange this token for a token for the Microsoft Graph API.
You can then use the token for Graph to call the necessary Users endpoint API endpoint for users.
I have a REST API, written with express directly. Nowhere in it do I use session, and authentification is for now done using JWT.
However, I dislike having to handle, save and secure user's credentials, that is when I heard about Azure Active Directory.
Adding passport to my app was easy enought, but that's when trouble started.
First, I had to search what strategy I needed, and all of them seems to require the server to maintain sessions/remember who is logged in, all the while using JWT internally. That seems contradictory, JWT is supposed to remove the need of maintaining session.
Finally, I found this MS example which use the Bearer strategy without session.
After setting it up (changing the config file for the right tenant, client ID, changing the routes for a test app more representative of my API), I tried to use them. The protection work well since I am indeed "Unauthorized". But how do I get a valid token to send?
The MSDN guide that use that quickstart don't mention it at all, just redirecting to the AAD library for Android or iOS, implicitely telling me to develop a test app in another language when I just want a crude tool to test if my test server work at all!
That is especially frustrating since I am pretty sure it is "just" a series of HTTP(S) request on the tenant, and the call to the api with the token attached, but I can't find anything to do just that.
/!\: I know asking for something as vague as "How can I do that" isn't a good question, and this question isn't one. What I am asking is why I couldn't find some tools like POSTMan that implement OAuth and allow to quickly test and debug a OAuth protected API. What are the reason that push MSDN to tell me to write a custom tool myself instead of providing a barebone one?
The code sample you mentioned in the post is using the Azure AD V2.0 endpoint. We can use OAuth 2.0 code grant and client credentials flows to acquire the token from this endpoint.
To compose the OAuth 2.0 request directly you can refer the links below:
v2.0 Protocols - OAuth 2.0 Authorization Code Flow
Azure Active Directory v2.0 and the OAuth 2.0 client credentials flow
In addition, the access tokens issued by the v2.0 endpoint can be consumed only by Microsoft Services. Your apps shouldn't need to perform any validation or inspection of access tokens for any of the currently supported scenarios. You can treat access tokens as completely opaque. They are just strings that your app can pass to Microsoft in HTTP requests(refer here).
If you want to protect the custom web API with Azure AD, you can use the Azure AD v1.0 endpoint.
For getting a valid token to send to your API, you'll need to do an auth request to login.microsoftonline.com and get an access token (in the JWT format). Then you can send this token to your api in the http body: "Bearer ey...".
If you want a full sample with a client app that hits that API sample you tried:
Dashboard w/ all the samples for Azure AD Converged Apps
Simple Windows Desktop App
Angular SPA
Node Web API
I'm working on Xamarin.Forms application where user should Authorize using Azure AD B2C. I've managed it just fine using this library.
Now I'd like to know if it is possible to authorize without redirecting to webview. When user enters email and password on app send a get request directly to an url and receive access token, refresh token and etc. Just like in OAuth 2.0.
I've researched and found out that skipping the webview authentication part is doable but extremely not recommended for security reasons but anyway, would be glad to hear any solutions.
Webview runs on SSL (https) and hence transmission of user credentials for authentication is secured.
It’s worth noting that you don’t have to use a web view for authentication; you may create your own user interface for this flow and pass the information back to MSAL.
- this is mentioned on the same blog-post which you referred to.
All you have to do is to design your own interface and pass back the login info. It seems like a little work to do.
so far I've not been able to get this working with the bot framework. I spent all day but only managed to get .net api example (https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet) working with AD B2C. I'm not sure where it grabs the bearer token that I want to pass to BotUserData...
I've tried following https://azure.microsoft.com/en-us/blog/bot-framework-made-better-with-azure/
but in reality the solution does not build successfully and I've resorted to just taking code from there and into my bot framework sample template....however, when it asks me to login through MS and I do, I am not able to proceed and it doesn't seem like that blog is using the AD B2C policies.
so how do you integrate AD B2C with Bot Framework? Is it possible to call /Account/SignIn URL from bot framework to authenticate the user? Afterwards, how would you capture the token and pass it to BotUserData?
You might want to take a look to the Facebook Auth sample to get an idea of a potential flow for the Auth scenario. For Azure AD, you need to do a similar flow.
Let's say your user send a "Login" message to your bot. The bot should respond with an auth URL and ask the user to login to the service using that URL. You can use the GetAuthorizationRequestURL method of ADAL for that.
Then you will have a Web API which will basically expose an endpoint that will be the reply URL of Azure AD. Once the users completes the login, a message will be posted to your Web API where you will be able to get the authorization code and perform the calls to get the Access Token. After that, you can just do the same they are doing in the Facebook Sample Web API which involves resuming the conversation with the Bot, sending a message with the access token (so it can be persisted in the PerUserInConversationData bag (check this line of code).
After that you have the access token available to perform any call that requires an access token.
Update
There are two new samples that you might want to take a look since they are implementing the workflow being discussed.
GraphBot from the BotBuilder repo.
AuthBot from Mat Velloso
Hope this helps.
Follow this tutorial for Bot side code development, i focus on configuration at B2C and Azure level here:
OAuth Connection
Client id
This is taken from the Application ID field in your B2C app's properties. It's the equivalent of a Microsoft app ID taken from any other AAD app registration.
Client secret
This is generated using the steps in this tutorial.
Select Keys and then click Generate key.
Select Save to view the key. Make note of the App key value. You use the value as the application secret in your application's code.
Use AAD V2 configuration in oAuth settings in bot channel registration - new oauth connection settings.
Fill the above details by following the steps and values we got from them.
Authorization/Token/Refresh URL
I followed on this one with
https://login.microsoftonline.com/tfp///oauth2/v2.0/authorize
for the Authorization URL and
https://login.microsoftonline.com/tfp///oauth2/v2.0/token
for the Token and Refresh URL's.
For I used the URL format (kyleorg.onmicrosoft.com) rather than the GUID format, but using the GUID also seems to work.
is the name of a user flow, like B2C_1_userflow. I created one with this tutorial.
Scopes
Using the scopes openid offline_access I am able to sign in successfully, but to my astonishment the token returned is empty.
Then I found this document which suggests using the client ID itself as a scope.
When I reuse the value from the Client id field in my Scopes field, a token is returned successfully and my bot is able to use the connection.
You can combine this with other scopes as needed, but for the sake of experimentation I highly recommend getting the simplest implementation to work first.
Let me know if these instructions work, and if they don't then we'll see if the difference lies in how we've set up our B2C apps.
As a bonus, I should mention that after you get a token you can paste it into https://jwt.ms/ to decode it and see if it recognized your B2C user correctly. Always refresh the page when pasting a new token to make sure it doesn't keep showing you the information from the last token.
Referred this document.