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.
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 have a Xamarin forms mobile application that is accessing my app service up in azure. I want to secure the APIs so that only my client application can access them. The mobile app does it's own user/password authentication/authorization, so I don't need AD or a 3rd party for that. I just want to secure my APIs. All examples I can find seems to assume there is an AD user authenticated and I can pass a token from that. Is there a simple way to use the Azure "expose api" functionality without using an AD user? The mobile app is using REST api calls, so I'm also struggling with how to even pass in a proper authentication token if I can put one together. Thanks in advance.
One way to secure is adding an API Management in front of your API's and require subscription, then only calls with a specific ocp-apim-subscription-key will be accepted. I don't recomment storing the ocp-apim-subscription-key value in your app as anytime you need to change it, a new version of the app will be required. I recommend returning it after a succesful login by your users, this way, you're free to rotate the ocp-apim-subscription-key key when needed.
Since you are trying to validate the client application only and not the end user, you should either look into OAuth 2.0 - which has a more complex implementation since it encompasses both application and end user authentications - or you could set up JWT authentication which is simpler and which purpose is to authenticate either client applications or end users, not both at the same time like OAuth.
After your implement the authentication on your API(s), you send over the generated token(s) over a Authentication header on your Requests.
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 using the express-stormpath package with a new application I've created in my account at Stormpath.com.
I use stormpath in my app I have to provide an application HREF provided in the application page in the stormpath admin, I also have to provide a API Key and Secret.
I've been creating a new API key/secret for every app I've made on the one admin tenant assigned to the account, the one I signed up with.
And I use that API key/secret to authorize my express application with Stormpath.
So in my admin account I have a long list of API Keys and I have no idea which key is for which app.
Is this how I should be doing it?
It just feels very messy. I see that normal application users can be given API keys/secrets, what are these for? Can I create an admin users for each app and use their API keys and secrets without making them a stormpath administrator?
Does that make sense? I've tried emailing the support directly.. but they didn't really understand any of this. :/
First of all, this is a great question, so I’m not sure why you’re being down voted. API keys can be a confusing topic. I’ll try to clear up the mystery around them before answering your specific questions.
In Stormpath, there’s two types of API keys: Tenant API keys, and Account API keys. Tenant API keys are what you need in order to make API calls to Stormpath. They identify you as an administrator of your Stormpath Tenant, and give you full read/write access to all of your Tenant’s data (in other words, anything and everything you’ve stored in Stormpath). By definition, an administrator has access to the Stormpath API and the Admin Console (aka the webpage you see when you log into Stormpath).
There’s also the notion of Account API keys. Accounts are people (or devices) that are signing up to use your web app, mobile app, or API service. In Stormpath, Accounts are stored in Directories, which in turn are stored in Applications. You can read all about this here. I like to think of Account API keys as a more secure version of a username and password. They’re really useful if you’re building out your own API service and want users to authenticate before they start making requests to your API.
That’s really all there is to it. API keys authenticate you — nothing more, nothing less. There’s tons of articles out there debating whether or not API keys are more secure than other methods, so you’re free to check those out. But in Stormpath, in order to communicate with our API, you must identify yourself as a Stormpath Tenant administrator. As you build out your own web app, mobile app, or API service, you can choose how you want your users to interact with your services.
I hope this helps clear things up.
If you want to create any other type of roles/permissions for your users, you’ll need to learn about authorization and how it works in Stormpath. I won’t elaborate on that here, but you can read all about it in our docs.
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.