What is the usage of client secret in azure active directory b2c? - oauth-2.0

What is the usage of client secret in Azure AD B2C? The Microsoft doc only said
If your application exchanges a code for a token, you need to create
an application secret..
Will the azure ad b2c encrypt the token by the client secret, or if a native app requests a token need to send the client secret to the azure ad b2c endpoint?
And, does the client secret can be used to make only my trust native app can get the jwt then to visit my server, third part untrust app can't get the token from the b2c to visit my server?
and what is the usage of application id uri?
thanks.

It has nothing to do with whether you are using Azure AD or Azure AD B2C.
client_secret is required for web apps rather than native apps because client_secrets can't be reliably stored on devices.
It's required for web apps and web APIs, which have the ability to store the client_secret securely on the server side.
The official document: Add a native client application to your Azure Active Directory B2C tenant also doesn't mention that you need to add a client secret.
What you have seen in Microsoft doc is for web apps.
and what is the usage of application id uri?
Application ID URI is the unique URI that is used to identify your API. When requesting an access token for this API, the whole URI should be added as the prefix for each scope.
If you have a web API protected and use another client app to access this API, you can enter the identifier used for your web API. See details here.

Related

How do I configure an Azure APIM Oauth2 service for Azure AD B2C?

I'm exposing an API through Azure API Management. In order to call the API from the developer portal, an Authorization header with a bearer access token, issued by an Azure AD B2C instance, needs to be provided.
In the B2C instance, there is a signup/signin userflow (with connector API integration to load custom claims) that should be triggered by the APIM Oauth2 service configured for the API. This would mean that the user flow is triggered from within the developer portal (try it functionality) and the issued token is used to try out the API.
Who can point me in the right direction to get this working?
Remark: this is not an issue about setting up AAD B2C to get access to the developer portal, it is purely about calling our API from the developer portal (try it) with a token issued by our aad b2c instance.
I already tried to configure the b2c authorization endpoint with the signup/signin policy passed as query parameter but without success. I would expected is needed to pass in the policy to be used to ensure the right policy is ran ...

Need an API design pattern where I can expose the same api to background process and end clients

Our apis are being consumed by 3rd party deamon applications as well as client applications. For third party deamon application we can expose the api via the client credential oauth flow and for the client application(S) we use the implicit grant outh flow.
The challenge we are facing is that in case of the implicit grant flow the user details are fetched from the ACCESS TOKEN. But when the same api is used for the client credential flow the user details can not be fetched from the ACCESS token as it has only application specific details.
What is the the best api design approach to handle the above challenge ?
Do I need two set of api(s) one for integrating with client application and one for integrating with server application ?
Will the usage of any alternative oauth flow help ?
Refer to Authentication scenarios for Azure AD documentation, as you stated correctly user interaction is not possible with a daemon application, which requires the application to have its own identity. This type of application requests an access token by using its application identity and presenting its Application ID, credential (password or certificate), and application ID URI to Azure AD. After successful authentication, the daemon receives an access token from Azure AD, which is then used to call the web API.
The quintessential OAuth2 authorization code grant is the authorization grant that uses two separate endpoints. The authorization endpoint is used for the user interaction phase, which results in an authorization code. The token endpoint is then used by the client for exchanging the code for an access token, and often a refresh token as well. Web applications are required to present their own application credentials to the token endpoint, so that the authorization server can authenticate the client.
Hence, the recommended way is two have two version of api implemented with two different type of authentication based on your scenario.
Reference -
Daemon or server application to web API
Understanding the OAuth2 implicit grant flow in Azure Active Directory (AD)

Can an Azure AD OAuth2.0 Access Token include custom data to identify the registered app to my API?

I have an Asp.Net Core 2.0 Web API running as a web app in Azure. My API is consumed by client applications which are windows service running on servers at various client sites. So, this is a "Daemon or Server Application to Web API" communications flow as described in Authentication Scenarios for Azure AD
I register the client application at each site as a separate unique app in Azure AD, obtain the ClientId and AppKey and send it to the respective site for their devs to use in their service to request a JTW access token from Azure AD to use in the authorization header when making an http request to my API.
This is all working just fine.
The question I have is this; is there any way, in this scenario, that I can identify which site is making the request? From what I understand, it doesn't seem like I can add custom claims to an OAuth2.0 access token, like can be added to an OIDC ID token.
If you register the apps yourself then you know all the client ids for each different site so your API could use the appid in the JWT access token (which is the client id) and cross reference it against a list of sites. Here is an example of a JWT token obtained using the client credentials grant type:

Getting Google Client ID and Client Secret for OAuth

I'm working with a company that is using the Google Apps free subscription. This company has a web site. They want to let users who have Google Apps accounts in their domain to authenticate into the web site via OAuth.
My question is, where do I find the ClientId and ClientSecret needed to do OAuth?
Thank you!
OAuth 2.0 for Client-side Web Applications will allow you to authenticate users using Oauth2. This will allow the users to grant your application access to their private data.
You will need to go to Google Developer console and create credentials on this page Credentials
Open the Credentials page in the API Console.
Click Create credentials > OAuth client ID.
Complete the form. Set the application type to Web application. Applications that use JavaScript to make authorized Google API requests must specify authorized JavaScript origins. The origins identify the domains from which your application can send API requests.

ADAL iOS Authentication to Azure Web API

Right now, I have a native azure app that my iOS app uses ADAL to authenticate to with no issues. I've added a Web API in azure and it's being managed by the Azure API Management resource. I have this API using an oAuth server that uses Azure AD for authentication (all created within the Azure API Management).
The issue I'm having is the oAuth token I'm receiving from my iOS App is not being accepted by my Web API. They are both using oAuth to the same Azure Active Directory. I tried changing in my iOS app, to use the Web API app client ID instead of the native app client ID. The issue then becomes during authentication, it needs a "client_secret" in the request. Looking at the ADAL iOS library, I'm not seeing a method to get a token that passes in a client secret as a parameter.
Scroll down to the Keys section, you will see the key as the client secret. They are used for calling the web api.
These two methods of authenticating the applications are referred to as interactive (user signs in) and non-interactive (app provides its own credentials). In the non-interactive mode, you must assign the service principal to a role with the correct permission. About the AAD authentication's more information, you could refer to: https://azure.microsoft.com/en-gb/documentation/articles/resource-group-create-service-principal-portal/

Resources