Here is what I am trying to accomplish -
A native application which is going to be run on a system where I cannot involve the user to login but I want to access web services secured behind AAD using a bearer token. There are two options -
Use a certificate based flow (which I want to avoid for few reasons
specific to my project)
Use the client secret
Issue I am running into:
When I call acquiretokenasync using the Native AAD application's client ID and a client credential built using the AAD web application's (which the native app has permissions to) client secret, I get the following error -
{"AADSTS70002: Error validating credentials. AADSTS50012: Invalid client secret is provided.\r\nTrace ID: f52cc954-2674-47ee-9a7b-094451b05c7c\r\nCorrelation ID: 1ba8ac64-cc4a-4ff7-83d6-a333504459d6\r\nTimestamp: 2016-08-20 01:45:08Z"}
So given that the client secret is indeed correct (which I am positive about), what could be the real issue behind this error?
Thanks in advance for your help :)
You can't use the native application client ID and web application client credential (client secret). The native application has no associated secret, only the web application has. Native applications are assumed to run on insecure hosts, such as the desktops and smartphones. Client secrets would become too fragile.
For more information on how to authenticate a native application and access resources, take a look at these articles:
Authentication Scenarios - Native Application to Web API
Developing Native Client Applications
There are two types of application which we can register in Azure Active Directory.
Select Native for client applications that are installed locally on
a device. This setting is used for OAuth public native clients.
Select Web app/API for client applications and resource/API applications that are installed on a secure server. This setting is
used for OAuth confidential web clients and public user-agent-based
clients. The same application can also expose both a client and
resource/API.
Native applications are public clients in OAuth2 parlance. Those apps are meant to run on a device and aren't trusted to maintain a secret - hence, their entry in the directory does not have the corresponding property. Without a secret, there is no way to assert the identity of the app - hence such apps cannot gain app level permissions and the portal UX reflects that. Conversely web apps are, again in OAuth2 parlance, confidential clients. They can get delegated tokens for their users, but they can also use client credentials to get tokens as themselves. Native apps can obtain tokens for the user via the OAuth2 authorization grant.
Refer this article further.
Related
We are in the process of developing a mobile (native) app, and are looking at how we should do user authentication. Most of the information I have found have been about web apps and / or third-party apps accessing public APIs. OAuth 2 is therefore recommended to be used most of the time.
Since we develop the app and our API isn't public, it seems like the Resource Owner Password Credentials OAuth 2 flow could be an option, but according to oauth.net that is not recommended any more.
We are using Google App Engine (with Node.js) and Cloud Endpoints (Not sure if end-points would be needed since it's a private API, but that is another question) as the back-end, and both Firebase Auth and Auth0 has built in support in Endpoints. However, we have some special requirements that doesn't make those services suitable (Swedish BankID for example).
What other options are there when authenticating users? Could we write an app in App Engine to check the users credentials against our database, and then send back a JWT (Cloud Endpoints supports custom authentication methods as long as they use JWT)? Would it be safe to do this ourselves? I have found some Node.js libraries for authentication, but most seem to be aimed at web apps. Are there any that are suited for a native app front end?
For authentication, yes, you can perform the check yourselves, in your database and deliver or not a JWT according with the authentication result.
However, and it's obvious, this authentication service must be public (because it's for authenticated unauthenticated users!). And thus, you can be expose to attacks on this service. And because it's the authentication service, if the service goes down, no one can no longer sign in, or worse, if you have a security breach, your user database can be stolen.
That's why, to use existing services, with all the protections, all the resources (people, monitoring, automatic response, high availability,...) deployed to managed a large number of threats. Firebase auth, Auth0, Okta (...) are suitable providers but I don't know your Swedish requirement and you might not avoid specific developments
I have a nodejs webapp with many users with a custom login process. I would like gitlab to accept that authentication and not force users to create a new app. What is the best way to accomplish this?
I would go for OAuth 2.0 Single Sign On (SSO). Below you can find the architecture diagram taken from here. As you can see the client is redirected to log in in the OAuth2 provider to get a valid token for authentication. The OAuth2 server must be configured for the application requesting access including the secret, the client id and the callback URL.
You can configure GitLab CE to sign in with almost any OAuth2 provider. Only be careful with the limitations:
It can only be used for Single Sign on, and will not provide any other access granted by any OAuth provider (importing projects or users, etc)
It only supports the Authorization Grant flow (most common for client-server applications, like GitLab)
It is not able to fetch user information from more than one URL
It has not been tested with user information formats other than JSON
You also need to configure your node js web application as an OAuth2 server. There are npm availables with the source code here.
Recommendation
I would install some open source Identity Management to separate the user management from your webapp, provides better integration with other third parties and forget about encryption and other stuff you need to take care in your webapp. There are multiple options such as KeyCloak for instance.
You have to define a dedicated user , and use the private_token of this user to login for ALL users that will use your application.
The restricition would imply all users will have the same rights ....
The other solution is to use the Private Token of the user at login. In this case , only the rights of these particular users will be used.
I have a scenario where I have to let external systems have access to one of our internal API's.
The security team want the externals to use client certificates as the preferred authentication method, so that basically leaves us two options:
Use direct client certificate authentication. It will give us the most control, but that will leave all the certificate handling and validation in our hands, and I'd rather not do that if I have a choice. Besides - direct client certification auth does not play well with our existing authentication methods on that API. If you turn on client certificates on the App Service, you will require a certificate on every request (and most requests on that API use cookies)
Add key credentials to the Azure AD app. We'd rather not give access directly to the app the API is registered on, so we register a OUR-APP-EXTERNAL and set up a trust relationship between the two. So the client authenticates with a certificate to the "external app", gets a bearer token and use that on our API. I'd prefer to use this solution, and it seems to play nicely with everything else.
So far so good - but I'm worrying about scaling this. We have to separate the external clients somehow (each client will in effect be different systems in different companies). One strategy is to create one AD-app per external system (OUR-APP-EXTERNAL-SYSTEM-A), but it seems cumbersome and somewhat spammy. One quick and easy solution would be to add some metadata from the client's authentication certificate (where we could just set what system this cert is issued to during creation), and add that to the bearer token.
Is this possible? Or are there other ways to handle "multi tenant" external clients?
Thanks
Consider an option of using Azure API Management for your scenario. API Management provides the capability to secure access to APIs (i.e., client to API Management) using client certificates. Currently, you can check the thumbprint of a client certificate against a desired value. You can also check the thumbprint against existing certificates uploaded to API Management.
Follow this guide - How to secure APIs using client certificate authentication in API Management
Also you can create multiple Azure AD Application for different clients and provide provide required roles to each of these Azure AD application to Azure AD Application registered to secure Internal API.
Follow this guide for this approach - Protect an API by using OAuth 2.0 with Azure Active Directory and API Management
I created an Azure Mobile App Service which is currently accessible 'Anonymously'
Anonymous access is enabled on the App Service app. Users will not be prompted for login.
To make it secure I can enable App Service Authentication which will ask users to log in
But this is not what I want - The data in this app is only accessed by Application without the need of each and every user to login to my app before using it.
So you might say, in this case, Anonymous access is fine but I want to restrict it with something at least like an API Key so I will have access to the API which my app can use to access the data to prevent random requests as anyone can just go and use Postman and start getting data without any authentication.
So in short, I don't want individual user authentication, but at least an API Key to ensure only requests made from my app are authenticated and nothing else.
I am using the following in my mobile app to create a connection and also doing Offline sync etc
MobileServiceClient client = new MobileServiceClient(applicationURL);
Any idea how do I do that?
FYI. My server side backend is in C#
Since you are using Azure Mobile Apps, for your requirement, you could leverage Custom Authentication for building your CustomAuthController to login and generate the JWT token for a specific user without user interaction. The core code snippet for logging would look like as follow:
MobileServiceClient client = new MobileServiceClient("https://{your-mobileapp-name}.azurewebsites.net/");
client.LoginAsync("custom", JObject.FromObject(new{Username="***",Password="***"}));
Note: As the above tutorial mentions as follows:
You must turn on Authentication / Authorization in your App Service. Set the Action to take when request is not authenticated to Allow Request (no action) and do not configure any of the supported authentication providers.
And you must explicitly add [Authorize] attribute for your controllers / actions which need to be authorized access. Details you could follow Authentication in the Backend.
I have developed a REST API with sailsjs and I'd like to add OAuth2 authorization to secure this API. I'm quite new to OAuth and I'm not sure where to start.
I found several modules that could be used for this purposes, for instance oauth2orize and an example of its usage https://github.com/aaron524/sails-oauth2-provider-example but I do not fully understand how this is working internally.
Basically, I'll have several clients consuming the API I'm developing:
- clients that I trust and that I'd like to use with the "Resource Owner Credential Authorization"
- clients that I do not trust and that will connect using the Authorization Code flow
I was thinking of adding a trusted property to the Client model within the sails application and then when a user will log onto an application:
- he will have a direct access to its resources (case of the trusted application)
- he will be requested to approve or deny the application from accessing his resources (case of the untrusted application)
Is this a good approach ? Any pointers on how to select the corresponding strategy based on the client trusted level ?
UPDATE
I've setup the following project on GitHub, using several tutorial and projects I found.
https://github.com/lucj/sails-oauth2-api
This project is not functional yet.
I'm still not clear on how to select the correct grant type (authorization code vs resource owner's password) when the user consume the API through an application. How to integrate this check in the policies ?
I do not manage to create the link between the OAuth endPoint (/oauth/authorize, /oauth/token) and the call to oauth2orize. Any idea ?
I finally struggled with Oauth2orize, sails and passport and managed to integrate OAuth2 security of my API in the project: https://github.com/lucj/sails-oauth2-api