For my project I'll have multiple daemon apps making calls to my API with tokens obtained by Client Secret keys. I need a way to identify which calls are coming from which clients, and I was thinking I could use the Description field that is set when adding a Client Secret Key in Azure AD administration. However I've parsed the token's entire payload, and I don't see it in there.
Is there a way to obtain that description using the token? OR is there another way to go about identifying different api users based on the secret key they're using?
No, you cannot know which key was used.
You need to register them as different client apps in Azure AD to differentiate them.
Related
I am using Azure Key Vault to store my connection strings.
The application that needs them is just a C# console application that will run in an Azure VM.
The problem is, I am unsure what the best practice is for storing the tenantId, clientId and clientSecret.
Should they be compiled in the code?
Should they be put in the app.config file?
Should they be put in the environment variables?
Should they be encrypted? Or is plain text for these fine?
If you would like to store the properties on your VM, you could use deployed service authentication(eg.Environment Variables, Managed Identity). Refer to here.
Managed identity is the most secure and recommended option for authenticating within Azure, see here. You could use managed identities to access App Configuration.
A service principal is a type of security principal that identities an
application or service, which is to say, a piece of code rather than a
user or group. A service principal's object ID is known as its client
ID and acts like its username. The service principal's client secret
or certificate acts like its password. Many Azure Services supports
assigning Managed Identity with automated management of client ID and
certificate. Managed identity is the most secure and recommended
option for authenticating within Azure.
Once you have assigned a managed identity to the virtual machine in Azure, you simply need the Azure KeyVault URL, without the need for a client id and client secret.
Keep in mind that you need to authorize the VM's identity to read from Key Vault.
Reference
I have a web application in C# through which I'm trying to get access token for Microsoft Graph API. I'm able to get tokens through using Client secret, but don’t want to get the token by using the client secret but get the token by other means, want to get tokens without client secrets.
I'm successfully getting the tokens using secrets and have stored them in KeyVault but getting an alert for "Explicit Credentials are being used for your application/service principals", so require some alternative to get tokens.
Is there any way to get tokens without secrets. Any help would be great.
One can use ROPC oAuth grant based on username and password instead of using Client Secrets to get access tokens. Microsoft identity platform supports the OAuth 2.0 Resource Owner Password Credentials (ROPC) grant, which allows an application to sign in the user by directly handling their password. Refer, https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth-ropc
Warning:
Microsoft recommends you do not use the ROPC flow. In most scenarios, more secure alternatives are available and recommended. This flow requires a very high degree of trust in the application, and carries risks which are not present in other flows. You should only use this flow when other more secure flows can't be used.
It is not a recommended way to use without client secret since due to security concerns.
If you still don't want to use client secret go with implicit grant flow which we can easily implement on the front end by maintaining SPA and passing token to the backend
I am developing an API using ASP.Net Web API to service a mobile app. I am using OWIN middleware with a custom OAuthAuthorizationServerProvider to handle the various grant requests for access tokens and restrict calls to authorised endpoints and this is all working fine.
I would like to restrict use of the API to the mobile app alone, using a secret key or keys. I understand this is not a 100% secure solution (possible reverse engineering / sniffing etc.), however I would like some guidance on the best practises to implement this.
The oAuth protocol already defines the use of a client id and secret, which I was thinking of using for the above purpose, however it seems the client id / secret are only checked when the access token is requested (ValidateClientAuthentication), whereas I would like to authenticate all API calls including generic, non-user related ones.
Another option would be of passing the secret key (client id / secret) in the HTTP header and checking this in a global AuthorizationFilterAttribute. This works but I am not sure whether it is best practise. Is there a generally accepted way to handle this scenario?
I'm developing an application that makes use of the OneDrive SDK nugget which uses Azure's App ID to authenticate API calls.
I'm not sure what's the best approach to implement that ID as I can't find any information about if it should be securely stored somehow or it can be implemented in a more flexible way (as plain text into a variable e.g).
Right now I'm storing that information in a separated file that has not been uploaded to github repository (as it's an open source project) but would like to know if that's not really necessary as it can be publicly avaible or there's a better way to handle it as I haven't used Azure Portal before.
Thanks in advance for the help.
The application ID / client ID is not really a secret, though I suppose there isn't really any upside to sharing it either :)
If your app uses an application key / client secret, well, that has to be kept a secret.
The application ID is submitted to Azure AD in the sign-in request URL, so it is available to users who sign in to your app and can't really be kept a secret there.
Relevant portion of the OAuth RFC:
The authorization server issues the registered client a client
identifier -- a unique string representing the registration
information provided by the client. The client identifier is not a
secret; it is exposed to the resource owner and MUST NOT be used
alone for client authentication. The client identifier is unique to
the authorization server.
I need to develop an external API, and I want to implement authentication with a client ID and a secret key just like Facebook, Twitter, Google and Microsoft do.
I have read some tutorials about OAuth2, but his generated token is temporary, and clients need to pass the username and password to get a token.
So, what I want is to give a client ID and a secret key to every client that will use my API, and they should pass this data on every method they call. Before returning the result, API checks if the request is valid.
What is the best way to do this?
I think what you're looking for is 'Basic Authentication'. Here's a very simple tutorial to follow in order to fulfill your requirements: http://www.c-sharpcorner.com/blogs/basic-authentication-in-webapi
It goes without saying that you should set your site to force https so that the credentials in request header are encrypted.