I currently have an API that I am opening up to our business partners to call, and I want it secured with OAuth.
I've set up an Azure API management (consumption plan right now) that points to our API in azure.
I can call it and get valid results in the test console.
So I was following the Microsoft documentation for this, and it had me :
Register my backend API in app registrations;
Register a client app in app registrations;
In azure AD grand the permissions for this client app;
Configure the APIM with a validate-jwt policy.
So now my APIM is returning a 403 as expected.
My question is this. I do not know the clients that will be using this API. Or rather, do I HAVE to register a client app registration? Or can I leave that part out, and just provide the URLS that I have for the OAUTH side, which are like :
https://login.microsoftonline.com/GUID/oauth2/v2.0/authorize
https://login.microsoftonline.com/GUID/oauth2/v2.0/token
I am very new to Oauth and APIM, so I am not even sure how all this works.
But it seems odd that I am registering an app for a client, when I have no information on them or how they are calling my API.
I kinda get that I need to know who is requesting the token and authorizing. But the clients will be using a javascript snippet that we give them to embed on their site, so I dont really know what their site is like, what their URL is or anything.
Hope that makes sense.
The client registration is what represents the entity (web app, mobile app, etc.) that requests for tokens from Azure AD for your API.
The docs walk you through a process where the developer portal is registered as the client.
The snippet in your case would also require a Client ID (of an app) to fetch the token with. For this, you would have to register a new app registration and share the Client ID as part of the snippet.
Related
I have a mobile app using Azure AD B2C which works fine. I can create an account, login, forgot password etc. That's all fine.
The mobile app stores data on the device.
The mobile app should also be able to push data to a remote database and trigger various functions via a .net core web api.
The mobile app should only be able to do that if it authorises itself successfully with the api using the credentials, or access tokens, it has from the login.
I assumed that this could be implemented easily (because, why couldn't it be?)
But now, after weeks of searching, hours of video-watching, 10's of aborted [test] projects, & 1000's of user accounts; I'm not sure whether the thing I want to do is a thing that can be done or should be done.
Thoughts?
Yes, this is of course possible :)
You can check the code samples for some examples of how to do it: https://learn.microsoft.com/en-us/azure/active-directory-b2c/code-samples.
Your mobile app can acquire an access token for itself.
You'll have to define in B2C that your app contains an API, and then define the app ID URI (an identifier for the API, not a URL).
You can then define scopes that API exposes.
These can be different permissions that applications calling the API can have.
In your mobile app you then acquire an access token using those scopes.
This token can then be passed to HTTP requests to your API, which the API has to authenticate.
Do ask if you want to know about something specific.
I have the following set up:
A web app (Jetty/Java)
A native client (iOS) (calling my webapp)
The Microsoft Graph API (called from my webapp)
The idea is that the user should sign in with OpenID/Oauth2 using his/her Office 365 credentials. The webapp will then call the Microsoft Graph API on behalf of the user (offline as well).
To achieve this I'm pretty sure I need to use the grant type: "Authorization code grant".
I can find a lot of example of the Oauth2 flow for browser based apps, and for when the native app calls the Graph API directly... but I want my backend to call the Graph API (and hold the access & refresh tokens).
So the question is how to do this properly? Here is my idea at this point.
From the native app: open a browser, call my web server which will trigger a redirect to the Azure /authorize endpoint (example: https://login.microsoftonline.com/[tenant]/oauth2/v2.0/authorize?client_id=[clientid]&response_type=code&scope=offline_access%20user.read%20calendars.readwrite&response_mode=query&state=12345&redirect_uri=my-scheme://oath2-code-reply
This will trigger authentication/authorization and then send the access code back to the app (using a custom scheme redirect: my-scheme://oath2-code-reply).
The app can then call my web app with this access code, where we can exchange the code for refresh & access code, and also create our own session for the user.
Is this the correct way?
Or should the entire flow occur in the browser and as the final step I open the app again with something like myapp-scheme://?sessionid=[our-own-session]?
For your scenario, you should use the on-behalf-of-flow.
A server-side sample that you can use as reference is https://github.com/Azure-Samples/active-directory-dotnet-webapi-onbehalfof - a note is that this sample is a .NET sample using a JavaScript SPA as a client - but hopefully it can guide you. You can use this sample for an overview on how to request tokens for your web api.
A note is that your item '1.' suggests that you are using the 'v2' endpoint. The 'v2' endpoint has some limitations, including for the scenario you are trying to accomplish (request access token to a Web API) - please see this document with information on these limitations, therefore my recommendation is to use the v1 endpoint at this moment for your scenarios -- which mean that you can only authenticate corporate accounts (and not MSA). The documents and samples I've indicated above uses the v1 endpoint.
I'm trying to create a web api in Azure that allows a user to access it.
I don't care whether the user calls the api via postman, curl or a .net console app, as long as the user can authenticate against the AzureAD protecting the resource, he should be in.
However, all documentation I have seen so far require me to register a client with AzureAD.
So, I've got an example working, but I had to register the console app in AzureAD.
Now, there maybe hundreds or thousands of developers developing apps against my API. Obviously I don't want to have to register each single one with AzureAD. In fact, I don't even want to have to know about them.
How can I actually do that? I care about users, not client apps.
Or is this something AzureAD B2C does?
Now, there maybe hundreds or thousands of developers developing apps against my API. Obviously I don't want to have to register each single one with AzureAD. In fact, I don't even want to have to know about them.
You only need to register one app(web app) to protect the web API. And if you want the web api consumed by different organization, you need to enable the Multi-tenanted feature on the Azure portal.
After that, if the other developers want to consumer the web API, they also need to register the one app on their tenant and grant you web API app to their app. After that then can acquire the access token for the web API and request the web API with the access token.
More detail about the scenario about calling web API, you can refer the code sample below:
active-directory-dotnet-webapp-webapi-openidconnect
And if the sencario is multi-tenant, you also can refer the document below about detailed info:
How to sign in any Azure Active Directory (AD) user using the multi-tenant application pattern
Not sure if that is possible: I would like to switch from server flow to native client flow in order to provide a better authentication experience for my users.
The problem is that Azure AppService requires a "web application" OAUTH setup (contains client ID and a secret), while the native login works with just a client ID and not secret. This means that after the login on the phone, I do have a Google token, but AppService wouldn't know what to do with it and returns me an HTTP Unauthorized.
The mobile client SDK gives me an API, but that doesn't work with such a token.
var jObject = new JObject(
new JProperty("access_token", auth.AccessToken),
new JProperty("id_token", auth.IdToken));
await ServiceClient.LoginAsync(MobileServiceAuthenticationProvider.Google, jObject);
Any idea on the proper way to integrate this without having to write my own server-side token validation?
You would still need to configure the web application in Google since you are attempting to access a non-Google API. The native login on its own is not enough.
That means you will still need to provide the backend with an ID and secret. The client is responsible for obtaining an id token and authorization code which get sent to the server, and the server does the actual retrieval of the access token, per the Google documentation.
So that means your call will actually look something like the following:
var jObject = new JObject(
new JProperty("authorization_code", auth.ServerAuthCode), // not sure what property your auth binding exposes this as
new JProperty("id_token", auth.IdToken));
await ServiceClient.LoginAsync(MobileServiceAuthenticationProvider.Google, jObject);
There isn't documentation for the end-to-end using Xamarin.Android, but you might find it useful to glance over the App Service iOS documentation for this scenario just to see the moving parts. The general pattern you will follow is:
Configure everything for the server flow (as you've done before)
Set up the Google Sign-in SDK (seems like you've done that already, too).
Make the call as described above
The main issue you might run into is making sure that you have the API console registration correct. You'll want to make sure you have an Android client there connected to the web application client ID you are using. I'd recommend giving the Google Sign-in for Android setup instructions a quick look. Also note that authorization codes are one-time use, and there are some throttles that Google puts in place for a user requesting too many of them within some span of time. You might run into that during dev.
AS far as I know, the native client flow also use the google code flow to get access token.
According to this article, the Android, iOS, or Chrome applications doesn't need the secret to get the access token.
The client secret obtained from the API Console. This value is not needed for clients registered as Android, iOS, or Chrome applications.
But the web app backend will not authorized this access token if you don't set in your backend to enable Azure App Service authentication/authorization. Because the backend will have its own logic(the mobile server library write the logic according to the access token) to return the auth token according to the access token.
Now, the most easily way to enable the client flow in your mobile app is set in your backend to enable Azure App Service google authentication/authorization with the same clientid and secret(based on my test: if you don't set the right secret, the backend will still return the auth token).
Here is the test image:
If you still don't want to enable the app google easy auth, I suggest you could create custom authentication which contains your own logic to check the accesstoekn and get the user information from the google.
If the checked result is success and get the enough value, you could generate the auth token and return to the client side.
More details about how to create custom authentication in the mobile app backend , you could refer to this article.
At my company we are developing several web applications that uses a REST API server.
First a little introduction.
The app provides the ability to manage users through the REST API and allows the users to login to the app.
Right now the REST API is for internal use only because we plan to develop more apps and communicate to the REST API as the central point of data access. We are handling the REST API authentication with a "Resource Owner Password Credentials Grant" implementation for the internal apps.
What we need is a Single-Sign on service for all the apps, we want a user to login to an app and if he/she access to another of our apps he/she will be already loged in.
We have been experimenting with the CAS protocol, with the CASino library specifically and it works great.
The problem is we don't know how to handle the flow between the apps, the REST API and the SSO service, also I don't know if there is a better choice regarding SSO services.
My questions are...
How we could handle the flow between the apps, the REST API and the
SSO service, because the REST API should be stateless it should not
communicate to the SSO service? or is there a way to communicate the
REST API to the SSO service?
Is there a better choice to implement a Single-Sign on service,
maybe OAth or OpenID and are this options suitable for REST APIs?
Thanks in advance!
Your REST API will have to talk to the SSO server to validate the Access Token, unless all the information it needs is encrypted inside the Access Token. Not sure what you mean by "flow between the apps", you should have all apps talking to a central SSO server.
When a user wants to create an account on WebApp1, the account should be created on the SSO server, either by redirecting them there or if you need a differently styled signup form for each web app, then via an AJAX call to the SSO server's REST API. I would recommend the latter as redirecting is more difficult to debug and it can make a bad user experience.
Make sure the messaging is clear, i.e. not "Sign up for a WebApp1 account", but "Sign up for a MyCompany account to get access to WebApp1".
OAuth 2.0 is very popular and people have more experience with it, so it's easier to get help or integrate with apps created by others.
The doorkeeper gem is a good server library.
OAuth 2.0 is normally used when the SSO server doesn't trust the client apps (e.g. Facebook, Twitter), but it can be implemented in such a way to skip the client authorization step (where the user is asked to approve the client app), and you can use the Resource Owner Password Credentials Grant via a REST API.
CAS is easier than OAuth. It is fairly easy to implement the basic endpoints and that way you can customize it as you wish.
I worked on a CAS-based server with a custom implementation (not sure if it was even really CAS-compliant). The authentication was done with Devise (I don't recommend Devise if you're going to customise it a lot, make your own in this case). The original flow was that the user went to the website, clicked Login/Register and then was redirected to the SSO server and after the user logged in, redirected back with a one-time ticket that the website's backend exchanged to an access token via a REST API call.
Then we added a REST API that was called from each website with AJAX. You send the username/password/captcha/etc and get back an auth token, which the site sends to its own backend. The SSO REST API can also set a cookie on its own domain, so that if the user visit another of our web apps it makes a call on pageload to check if the user is logged in. This way you're automatically logged in on every webapp without the redirect mess.
All tokens issued + the associated user info were sent to a fast Node.js app that would save them to Redis, and the app backends would call this app to validate the access tokens really fast, without putting load to the SSO Rails app.