How can I add claims to a JWT assigned with auth0 for a machine-to-machine application type? - auth0

I am using auth0 as OIDC provider for single-sign-on.
So far I tried login with two application types, on the one hand the native application type and on the other hand the machine-to-machine application type.
However, when I login, I only receive a very simple id_token with the following payload:
{
"https://example.com/roles": [
"user"
],
"iss": "https://my.idp.provider.com",
"sub": "oauth2|someconnection|samlp|somecompany|someusername",
"aud": "REMOVED",
"iat": 1547652649,
"exp": 1547688649
}
I want to add a group claim to this token. How can I configure my Auth0 tenant to add "group": "admin" as claims? Do I need to enable a particular scope in my authentication client to receive the groups claim?
I have installed and configured the Authorization Extension in auth0 but that did not have any effect on the claims in my token. I know that the Authorization Extension does not support machine-to-machine applications. Therefore, I added the native application and tried to login with that, but that also did not return any additional claims.

After configuring the Authorization extension, you can add custom claims to the issued JWT tokens from Rules. There's a sample rule here that does the job: https://auth0.com/docs/extensions/authorization-extension/v2/rules#add-custom-claims-to-the-issued-token
You can customize the Client Credentials token as well using the Hook: https://auth0.com/docs/api-auth/tutorials/client-credentials/customize-with-hooks
EDIT: OIDC Comformant Apps require you to define the namespace because Authorization data such as roles and groups are not OIDC claims.

Related

Cannot authenticate to custom API in Azure AD (JWT token issue)

I have a JWT token issue when trying to the use the AadHttpClientFactory within the SharePoint Framework (SPFx). I have a custom AAD App registration that is setup to allow implicit grant flow. I have another app service running a small .netcore API that requires authentication. My API is not setup to authenticate the user, rather it validates the token coming from the Authorization header using the following Azure AD values.
"AzureAd": {
"Instance": "https://login.microsoftonline.com/",
"Domain": "domain.onmicrosoft.com",
"TenantId": "09e6b9a6-59fc-419d-xxxx-xxxxxxxxxxxx",
"ClientId": "f46a1554-7fd9-4627-xxxx-xxxxxxxxxxxx",
"ClientSecret": "xxxx-xxxxxxxxxxxx",
"Issuer": "https://login.microsoftonline.com/09e6b9a6-59fc-419d-xxxx-xxxxxxxxxxxx/v2.0"
}
I have my SPFx service setup to fetch the client like this:
this.aadHttpClientFactory.getClient("api://URI").
It then calls my custom service, but no matter what I do I get a 401.
If I use the following URL to fetch a token and use it to hit my service it works fine:
https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/authorize?client_id=<client-id>&response_type=id_token&redirect_uri=https://localhost:5001&scope=openid&response_mode=fragment&state=12345&nonce=678910
So, I inspected both JWT tokens (one coming back from SPFX and one I generate using the URL above).
They are vastly different. The token I get back from SPFx has much more information in it and the Issuer is https://sts.windows.net/<tenant-id> but my API is looking for https://login.microsoftonline.com/<tenant-id>/v2.0 as the issuer. I feel that the issuer is where it is failing but I have tried updating my API to use the issuer that is coming back from SPFx and it still doesn't work.
Any ideas?
Found this post that said the audience was invalid. I was able to find the same error inside my response. I updated my client ID to match my api URI of api:// and it worked.
Azure AAD - The audience is invalid

Client Credentials flow with AAD B2C

I have a SPA React app with a NetCore API backend. This api is also used by another application.
I want to authenticate and authorize the SPA users using AAD B2C and the second app using the client credential flow. I understand that client credential flow is not supported by B2C. And I read that to achieve that I'd need to register the api again in Active Directory (non-B2C) as well as the client app and configure that using normal AD.
That will leave me with SPA and API registered as apps in B2C and API and client app in normal non-B2C.
IF.... all that is correct, how do I make the API validate both different types of clients? Authorizing users from B2C and client app through client credentials flow against AD non-B2C
For authorizing users from B2C, you just need to refer to this document: Tutorial: Grant access to an ASP.NET web API using Azure Active Directory B2C.
Your main concerns is for client credentials flow against AD non-B2C.
I have a test and the steps are the same as in the normal AD:
I registered a web API application in Azure AD B2C. Add an appRole in its manifest.xml.
"appRoles": [
{
"allowedMemberTypes": [
"Application"
],
"description": "Writers Have the ability to create tasks.",
"displayName": "Writer",
"id": "d1c2ade8-98f8-45fd-aa4a-6d06b947c66f",
"isEnabled": true,
"lang": null,
"origin": "Application",
"value": "Writer"
}
]
Then I registered a web App application in normal AD. Add the API permission to it.
Use client credentials flow to acquire the access token.

How to use Firebase Authentication with Okta?

I am currently using Firebase Authentication in my app using the built-in OIDC providers (Google, Facebook etc.). Is it possible to use Okta as an additional OIDC provider with minimal modifications to my app, meaning Okta should behave just like any other built-in provider? Firebase Auth apis, such as firebase.auth().currentUser and firebase.auth().onAuthStateChanged() should still work.
The doc page for Custom Authentication talks about getting a custom token from an auth server, but does not clarify if that's an OAuth access token. Is there an example of Okta integration or a generic OIDC integration that works seamlessly with Firebase auth?
There's no built-in Okta provider for Firebase Authentication, but if you have an existing authentication flow for it, it's fairly easy to integrate it into Firebase as a custom provider.
It's a 6 step process:
You gather the user credentials on the client.
You pass those credentials to a trusted environment, either a server you control, or Cloud Functions.
On the server you verify that the credentials are correct according to Okta, typically by calling a server-side API they provide with a key you provide.
You then use the results of that call to mint a new ID token for the user. This is a JWT, not an OAuth access token.
You pass back that ID token from the server to the client.
The client then calls firebase.auth().signInWithCustomToken(token) with the ID token, to sign in to Firebase Authentication.

Standard Implementation in Getting Access Token and Basic User Information via Resource Owner Password grant with OpenID Connect

I want to authenticate a user's user name and password, and upon success, I want to use the token to get basic user information.
The grant type is Resource Owner Password grant with OpenID Connect.
However, there is a difference in how this is implemented in various identity providers. For example, OneLogin requires two requests to get the basic user information. While, Azure AD B2C and IdentityServer4 require one request.
Which implementation is the stardard of OpenID Connect? If OneLogin is used for my project, what best practices are available for platform portability?
OneLogin:
First Request:
Getting Token
Url: https://openid-connect.onelogin.com/oidc/token
Ref: https://developers.onelogin.com/openid-connect/api/password-grant
Result:
{
"access_token": "example",
"expires_in": 2313232,
"token_type": "Bearer",
"refresh_token": "example"
}
Second Request:
Getting User Info
URL: https://openid-connect.onelogin.com/oidc/me
Ref: https://developers.onelogin.com/openid-connect/api/user-info
Result:
{
"sub": "123",
"email": "my#lmail.com",
"preferred_username": "my#email.com",
"name": "My Name",
"updated_at": "2019-03-13T16:11:15Z",
"given_name": "My",
"family_name": "Name"
}
This is partially down to the "open" definition in OAuth2 around the token definition. In Azure AD, the Access token is a JWT which provides basic user information. Get an access token ( via whichever grant type ) and you have basic user info. In Onelogin ( and other IdPs such as Salesforce ) the access token is just an opaque token that contains no discernable data. It's a token to access resources.
So there's no standard here, but if you're looking for consistency you should assume the access token from any IdP does not contain user information. Either initiate a grant that returns an OIDC token or use the access token to request and API endpoint that returns user information. Note, the Resource Owner Password Grant should with an openid scope should return an id_token which includes your basic user information.
This ( new tool ) should help clarify as well
https://youtu.be/do0agd71hE8
I would suggest sending the Identity Token to the resource server usually your api server( it take it you in you intend to secure this ?. As the Identity Token is a JWT this can be validated locally on every call on your resource server/api server. You can use the opaque bearer token initially to obtain info from the userinfo_endpoint about the user. Since the bearer token is opaque there is little point passing this to your api / resource server since you have no means of validating it.
There is a big discussion IdToken vs AccessToken sent to Resource Server
It is not normal to send the id token to the resource server, but since the bearer token is opaque and can not be validated locally you have little choice

Web API: authorization or/and authentication

I created asp.net web api project. I need to add authorization or/and authentication. I've read a lot about OAuth, SAML, JWT, HMAC etc. and everytime I see author emphasizes that OAuth is not authentication and you need to differ authN from authZ. I'm a bit confusing because I don't understand:
when I need to use authentication (SSO, login/password) and when authorization(OAuth, tokens) for API?
are HMAC, JWT for authorization or for authentication? because they are signed and I can add userid to this token use like user identifier
what are real differences between authN workflow and authZ workflow?
OAuth can be also used to authenticate users using a resource owner grant (i.e. a client gets an access token providing an user+password credential).
The resulting access token is what you should call authorization, since it will contain info like claims describing permissions, permission masks or roles (it depends on what authorization scheme you implement in your solution).
A JWT (JSON Web Token) is just a JSON representation of both access token and any other associated info. JWT is the content of some authentication result which can be used to be authorized against some resources. Since the JWT contains an access token, if you're using basic authorization, you'll add an Authorization header to your requests: Authorization: Bearer [your access token].