I know that it is not a secure practice to have any secret tokens in configuration files, however I have been unable to find out if the application ID is considered a secret. Would having the app ID in config.json be acceptable or not?
No, Azure App ID is not considered to be a secret. In case of native apps and web apps, the Azure App ID is quite visible, as a URI parameter, to the client in the browser redirect during authn/authz.
Related
The azure app service provided an URL in such format https://your-app-name.azurewebsites.net
When Expose an API in azure app registration the Application ID URI is needed. But when I use the url provided by the azure app service I got the following error:
Values of identifierUris property must use a verified domain of
the organisation or its subdomain: https://your-app-name.azurewebsites.net
the URL provided by the app service is not a verified domain? and how can I make it verified?
Application ID URI is an identifier that can be used instead of the client ID when specifying a scope defined in that app.
It has nothing to do with authentication redirect URIs, where it would need to match your app hosting.
Agree with juunas and this is just additional description. Screenshot below contained the error you met and one of the supported App ID URI pattern.
I'm afraid that the reason for exposing API is that you want to protect your web API with Azure AD. The App ID URI here is used for the authorization. Your web app also requires to configure the audience, then after you integrate Azure AD authorization into your application, the scope, the audience and other claims containing in the incoming access token will all be verified. I have a sample which is based on a web api. You can see the configuration for Azure AD authorization.
And https://your-app-name.azurewebsites.net is for authentication which used for redirect from microsoft identity platform back to your own web app. The scenario can be opening your own web page which requiring user to sign in --> redirect to microsoft sign in page --> sign in then redirect back to your web page. So we need to identify the redirect URL in Azure AD.
Using authorization flow and passing the information to the back-channel for the token request we don't need to save the secret in the app.
Why then does Azure force us to use a public type?
Cannot choose for the app to be a 'web' type as the redirectUri is not allowed to be anything other than 'https://foo' which in our case is 'app://auth'
edit: More information
When adding a platform on Azure AD you currently have the option between
web
spa
ios/macOS
android
mobile and desktop application
All of these are public clients except 'web' which can be confidential as the back-end is able to securely store the secret. My question is why is there a difference between web and for example an android application? The android app will communicate the exact same way a front-end application would. But choosing the android app is the only way I can configure the redirectURL for my application
An SPA being public is understandable, but forcing every mobile app to be public is something I do not understand
MOBILE FLOW
This has some differences to a web client. You are meant to use Authorization Code Flow (PKCE) without a client secret, and sign in via a Chrome Custom Tab. See this Curity tutorial for how that looks. Avoid using a web flow for a mobile client though.
MOBILE CLIENT SECRETS
Routing requests via an API that attaches a client secret is not considered standard since an attacker with your client ID and redirect URI could still trigger a flow on app:/auth.
If mobile client secrets are needed then the recommendation is to ensure a different client secret per device. This can be done using Mobile DCR. I don't think Azure supports this however.
HTTPS REDIRECT URIs
In case you're not aware, Android App Links are needed in order for mobile apps to receive authorization responses on HTTPS redirect URIs. I'm pretty sure Azure will support this, and it is a best practice since an attacker cannot get the response. More about this in a blog post of mine.
An "OAuth client" is the application which talks to the Authorization Server. In your case, you don't have a mobile client, as it's in fact the backend which talks to the authorization server. A mobile client should never be configured as confidential. Azure can't assume that all developers will be as thoughtful as you and don't hard-code the secret in their apps.
As #Gary Archer pointed out you should configure your client as a web confidential client and use HTTPS redirect uris as an Android App Link to go back to your app.
Using authorization flow and passing the information to the back-channel for the token request we don't need to save the secret in the app.
It sounds like you relate to a newer Client-Initiated Backchannel Authentication Flow. Azure does probably not support this flow, yet.
Why then does Azure force us to use a public type?
The confidential client and public client terms stems from OAuth 2.
A confidential client is an application that is able to protect its client secret. E.g. a backend application in e.g. Java, Node.js or similar.
A public client is an application that is not able to protect a secret - or where many unique instances exists. E.g. JavaScript Single Page Applications or Mobile applications - this is places where a Secret could be extracted in any client. It is now common to use a Proof Key for Public Exchange when using a Public Client.
Also see What's the difference between Confidential and Public clients? - OAuth in Five Minutes.
For Azure Active Directory, I created an app registration for my web app to enable SSO/OAuth 2.0 login for end users and to do AD lookups using the AD graph apis.
That requires me to use a client id and client secret and I have the requirement to not store the secret on the system when running inside of Azure VMs.
Is there a way using managed identities to either fetch the application secret or generate a token that can be used with the login.microsoftonline.com OAuth end points?
When you say "Web App" I'm making the assumption you are using something along the lines of an Azure App Service,
If the issue is with storing the client secret locally on the machine, the more secure way is to store the secrets in Azure KeyVault.
This stackoverflow post goes over why KeyVault is secure : Why is Azure Key Vault secure?
And the official docs provide a good overview/quickstart on getting started with Azure Keyvault. https://learn.microsoft.com/en-us/azure/key-vault/quick-create-portal
And this is a tutorial on using KeyVault with an Azure Web App: https://learn.microsoft.com/en-us/azure/key-vault/tutorial-net-create-vault-azure-web-app
Essentially secrets stay in Azure so that they're never exposed in code or on the development machine. And by using MSI, you won't need to keep track of credentials to access the keyvault. Keeping all important information in Azure.
I'm working on setting up a new SSO application. I would like to use ASP.NET Identity as a database to store the users data. I have a ReactJs application hosted on Node.JS and a .Net Web Api2 application. I want to protect thsi Web Api 2 using Identity Server with users from its database. In further development I'm going to create a mobile application.
I'm able to create an asp.net identity database with some users and use Resource Owner credentials, but I have couple of questions if anyone could help:
Why is Resource Owner Credentials not recommended? My current workflow is to hit the api with client&user&password and obtain a token which I store in web layer and use in Web Api requests. Web Api validates the tokens and identify the user. I read on IS page that's not recommended then what's the recommended scenario to authenticate the user?
How can I create an authenticator for mobile? Should I create my own certificate issue, store it in database as a thumbprint and use access token for that?
Thanks
In short, Resource Owner requires the credentials to be passed through the application itself, also RO doesn't give you SSO. Here's a longer answer. The recommended scenario is to use hybrid flow with PKCE enabled.
Look up TOTP. I believe it is implemented in AspNetCore.Identity with some examples.
I have a REST backend secured with OAuth2 and a mobile application.
I would like to use the Resource Owner Credentials flow to authenticate the user from my mobile application.
Since I must provide a client_id to identify the application which is requesting authentication, how can I prevent a hacker to steal my client_id from my mobile application source code, and how can I revoke it ?
I really would like to know how the official Twitter Android application for example handle this kind of thing.
I know this is a very old post, but I just came across it in an unrelated search and saw it was unanswered.
To quote from the OAuth 2.0 spec,
The client identifier is not a secret; it is exposed to the resource owner and MUST NOT be used alone for client authentication.
In other words, the client_id is very similar to a username or email. I certainly wouldn't mind if someone found out my email address, even though that is half of the data required to log in and view my emails. To keep to that idea, the client_secret is a password that should be kept private through guarding your source code and sending POST requests only to HTTPS endpoints.
As for revoking privileges granted to clients through those credentials, most (if not all) major OAuth providers will allow you to do something through their OAuth portal. To follow your Twitter example, they have a button on the API Keys page to "Regenerate API Keys." If you are the service provider (I say this because you mentioned having permissions to Resource Owner Credentials) and you don't have a public-facing OAuth portal set up, it would be simply a matter of changing the strings in whatever data-store you use server-side, then making the same change in your client source code.