My web api services are protected by roles based authorization. So, my access token requesting from Azure AD doesn't include any roles in access token. Is it possible to add assigned roles(defined in manifest file and adding it on user) into access token?
would you please guide me with links and examples because I am not able to find any documentations?
Definitely possible, I've written an older article on the topic: https://joonasw.net/view/defining-permissions-and-roles-in-aad.
Make sure you define the roles in the manifest of the API.
Do note though that if a user has many roles and you use the implicit flow to get tokens in the front-end, they might not appear in the token.
If that happens to you, upgrading to MSAL.js 2.x and using authorization code flow with PKCE in the front-end should help with this.
Related
I have created Azure AD B2C Application and tried to integrate with React JS using MSAL Library , When i tried to get access token I am getting following error.
AADB2C90205: This application does not have sufficient permissions against this web resource to perform the operation
Any Help would highly appreciated.
The link provided by #Jas Suri is correct, but I need to add some more:
You need to create two applications, one representing the client application and the other representing the api application, and then use the client application to call the api application.
Next, you need to expose the api of the back-end application and record the scope name, then go to the client application to add the scope to the API permissions (you need to find it in My APIs), and grant the admin consent to the permission.
Finally, when you get the access token, you must add the scope.
You didn’t grant admin consent. Follow this:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/add-web-api-application?tabs=app-reg-ga
Specifically the Grant Permissions section.
So here is my dilemma or my somewhat up in the air question .
I have set my self with with a scenario in such that I've enabled SSO on Salesforce using ADFS certs, but currently all users have access to go through salesforce using SSO. I'd like to limit SSO to only three groups "user groups defined in AD" to be the only ones to be able to use SSO in salesforce.
I know i need to delegate access but not sure if i need to do this on the ADFS side or the salesforce end.... on ADFS the only thing i've done is create the certificate and brought them in salesforce and then taken the XML generated and bring that into ADFS.
Any help would be greatly appreciated it .
After Searching the web and this form i came to realise that there is a Delegated Authentication and i might need to install a Delegated Authentication WSDL not sure if this step is necessary for ADFS 3.0 .
Many people seem to point to using Delegated Authentication , but i'm wondering if there is any way to get the same functionality using claim tickets on the adfs server.
Thank You Again :)
You seem to describe something doable via AD FS authorization rules. Read https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/when-to-use-an-authorization-claim-rule
Essentially what you do is on the relying party for Salesforce in AD FS, you create authorization rules to permit/deny based on AD group membership. Therefore, if user is in group, AD FS issues token. if not, they get a deny which means no token that would allow access to Salesforce.
Also see https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/operations/access-control-policies-in-ad-fs because based on your AD FS version you may be able to do this via an access control policy instead of issuance authorization rules.
As shown by many samples I have two AAD application registrations, one for my javascript-based front end, and one for my JSON-only web APIs.
If I fully trust my client AAD application, why does AAD require me to create a second AAD application for my web APIs?
For example, assuming I add specific roles to my client AAD application, if client signs in with AAD and gets an id token and access token containing my roles, it only needs to send the access token to my APIs. The API only needs to crack the JWT, validate the audience, issuer, tenant, roles permissions, and signature. In this world, no client secret is needed in the web APIs, a second AAD application registration not needed, and still no call to AAD from my APIs. Unfortunately, without two AAD applications, I cannot figure out a way to have AAD include roles into my access token.
If I didn't fully trust the issuer from mucking with claims, I can see why I would need two AAD applications and a client secret. But since I do trust my AAD application and the signature of the JWT, why the extra complexity? Or maybe there is a way to do this that I haven't found?
Thanks!
Responding to Marc here because just not enough characters in the comments field -- The sample you referenced is an excellent sample, specifically the JavaScript one calling the Web API. It is what I am doing right now in fact. However, the problem is that Web API in the sample is open to anybody who has authenticated on the tenant. I need to secure the Web API down to certain individuals in the tenant, and simply checking the client/app id is not sufficient as anybody who can create an AAD app can fake it.
So what I need to do is have roles added to the the access token so I know that my application authenticated the user, and that user has been granted the required roles. For example, here is a Microsoft sample. And even here a Microsoft video walking through the process.
If I don't have two AAD applications w/client secret, the roles claims is never provided in the access token. It is always provided in the id token, but not the access token.
I feel like I am missing something obvious here. If AAD would just put the roles I requested into the JWT when I authenticated against it, and I validated its signature, audience, issuer, and roles, I wouldn't need any of this extra complexity?
Ah, I think I understand where you are going: you would like to control which users can access an API, no matter what client app they are using to access the API with. That's a function of the API - you cannot control that through AAD. In AAD you can control which users can access which applications (UI) using either user access restrictions (enterprise tab) or role-based access. However, access to an API is controlled in AAD at the calling application level via scopes. APIs are never accessed directly by users but only by other apps so controlling access permissions at user level would cause admin havoc. So, you can control what permissions a user has in the app they are using and you can control what permissions that application (client) has in other applications (APIs, resource servers) it is using.
In other words: role is about user access to UI, scope is about one apps' access to another.
App secrets provide added security for getting tokens - they have no bearing on what permissions are included in the token.
Can you provide a link showing that two apps are needed? That should only be the case if the API you want to call is not provided by the web app which served the JS to the browser. None of the 'official' samples require you to register two apps (Graph API, used in some of these samples is a separate API and it is already registered). A problem with tokens passed from the browser is that they were acquired by a public client, not using any secrets apart from user creds. Therefore, they are easier to steal and re-use. Your own back-end app may want to use a secret to get its own token (extension grant) to call yet another API using a token that does not reside in a public client.
Sorry I am still very confused, read everywhere telling me oath is a authorisation protocol but it appears using the azure ad oauth code grant, it does promote a login screen to authenticate against the directory, so is it not an authentication process? what is the relationship between the open id connect? thanks!!
the OAuth2.0 protocol has several flows that an identity provider (in your case Azure AD) may implement to support auth.
The Auth Code flow is in fact one of these used by apps to get access tokens for some api. The flow is quite simple, an app redirects the user to the identity providers /authorize endpoint. At this point the user enters their credentials, and the site redirects back to your application with an authorization code and can also issue an ID Token that represents a user (This is the OpenID Connect part). The app takes this code, and POSTs it to the /token endpoint and will be issued an access token and refresh token. With the access token, your app can access whatever api you've requested access for.
For Azure AD specifically, Microsoft has built libraries that handle all these flows and token caching so most of the complexity is abstracted away. There's some simple code samples that you can checkout that you may find helpful. The authentication protocols and scenarios doc for Azure AD may also be really helpful for conceptual information.
I'm trying to debug a problem with Google's Oauth2 system where I'm seeing multiple authorizations to our single server-side account. Does Google provide a way to get a list of authorization tokens / refresh tokens issued to our application? I don't need the actual token values per se, just a list of users and permissions. I haven't been able to find anything so far in Google's documentation.
I will suggest checking out the Admin SDK's new features on user tokens.
https://developers.google.com/admin-sdk/directory/v1/reference/tokens
The Directory API allows you to audit access tokens that have been issued to 3rd party applications using the OAuth protocol. Authorized applications are granted access to a limited scope of user data, defined in the access token.
Related Google Apps Developer blog post: http://googleappsdeveloper.blogspot.com/2013/11/new-security-management-features-for.html