I've a OKTA project which OIDC - SPA.
We have implemented micro service architecture in the BE so there are multiple services which accept auth-token from users which are minted by above SPA application. Now, I want to enable microservice communication and want to have some kind of authenticaion between them.
Below is what I want to achieve:
Inorder to acheive this I need to create an application with type Web Application because I need clientId and secret inorder to generate a serverside token.
I currently have a SPA, here are my options:
Create new application with type Web Application and use SPA on FE and WA on BE.
Get rid of SPA and use WA on both FE and BE.
What are the consequences of either approaches?
Related
I have a DotNet Core WebAPI living in my own Azure AD tenant. This WebAPI is secured via AzureAD V2 (!) BearerToken authentication. This API is called by an Angular SPA authenticated via OIDC (AzureAD v2) using #azure/msal-angular following the tutorial at https://learn.microsoft.com/en-us/graph/tutorials/angular. Everything works fine with users from my own tenant. But when logging in with a user from another tenant I get the following error:
"AADSTS650052: The app needs access to a service
(\\\"https://mytenant.de/AngularDemoApi2\\\") that your organization
\\\"myorganization.de\\\" has not subscribed to or enabled. Contact your
IT Admin to review the configuration of your service
subscriptions.\r\nTrace ID: 9597578e-7e48-49b2-85be--b5a1ee14300\r\n
Correlation ID: 30d4caf2-e3ca-4d7d-84b5-564d428e4e69\r\n
Timestamp: 2019-06-13 15:40:46Z|invalid_client"
I have tried to following some examples to make the WebApplication and the WebAPI multitenant but all the examples seem to be outdated and/or not relevant for V2 of Azure AD. WebApplication and WebAPI have set
"signInAudience": "AzureADandPersonalMicrosoftAccount"
in Manifest. WebAPI has App Uri in the form of
https://mytenant.de/AngularDemoApi2"
I guess that I need to give users from other tenants somehow permission to access the WebAPI in my tenant but I don't know how.
Edit: When I choose to expose the API directly from the app registration of the SPA it works like a charm. But this approach does not seem to be right because each exposed API would have the same audience ("aud" claim, the same audience as the SPA application). In my example above I have a separate app registration - one for the SPA and one for the API. This way each API would have it's own audience and it will also be mentioned in the consent screen.
May be someone could explain how to configure it correctly?
I had the same problem, and for me the solution was to add the client as an "authorized client application" to the WebAPI's app registration in the Azure portal.
This will show up in the service app's manifest as a section in the following form, where appId is the application id of the client app, and permissionIds contains the ids of the scopes requested by the client app, which can be read from the "oauth2Permissions" section of the manifest:
"preAuthorizedApplications": [
{
"appId": "523ca2d4-680b-4ef4-8a8c-3f3486693cf7",
"permissionIds": [
"35e5e006-83c5-4f37-a3bf-c048ee8c8600"
]
}
],
In your case, you might have to first register the Angular SPA as a client application in order to get a client id. This is described in this quickstart.
I have a mobile app which gets token directly from azure login. And I have a service which is using adal4j in spring boot. I cannot use the mobile generated token to authenticate spring service. Becase I use two different azure app registrations for mobile and web service. Is there a way to accomplish this ?
My understanding is that you have created 2 Enterprise Applications in Azure.
1) An Enterprise Application for your mobile app (Type: Native)
2) An Enterprise Application for your Web API app (Type: WebAPI)
For native app, you will not need a client secret but you will need a client secret for the Web API app.
Now coming to the key configurations:
In both of these, please update the manifest file to have oauth2AllowImplicitFlow set to true
Also, in your Web API Enterprise Application, please have the app id of your native app in the known client apps
"knownClientApplications": ["
Now, when calling your Web API through an end-point from the Native application, pass your token in your request header as "Authorization": "Bearer "
Also note: if you need to retrieve group claims, please update the manifest in both your enterprise apps to have the following setting for this property
"groupMembershipClaims": "SecurityGroup"
Update:
Under permissions in the native app, please add the Web API app registration to allow access
Yes, the OAuth 2.0 on-behalf-of flow should applies to your scenario. These steps constitute the On-Behalf-Of flow.
Azure AD issues a token for certain resource (which is mapped to an Azure AD app). When we call AcquireToken(), we need to provide a resourceID, only ONE resourceID. The result would have a token that can only be used for the supplied resource (id). There are ways where you could use the same token , but it is not recommended as it complicates operations logging, authentication process tracing, etc. Therefore it is better to look at the other options provided by Azure and the ADAL library. The ADAL library supports acquiring multiple access-Tokens for multiple resources using a refresh token. This means once a user is authenticated, the ADAL’s authentication context, would be able to generate an access-token to multiple resources without authenticating the user again.
Further details here.
I currently have an asp.net Web API that uses identity authentication which an angular client then uses to authenticate users using an access token.
I want to have a another separate restful API that deals with the logic, crud operations etc side of things but I want this to have [Authorise] on the controllers to ensure it is secure.
What would be the best way to achieve this? Do I have to install identity on this logic API too?
Any help on this would be really appreciated.
I will draw a scenario, and need some suggestions:
I'm using Azure AD (v1.0 endpoint), a single-page app (SPA) and a web API. The SPA establishes the user's identity using OpenID Connect, authenticates the user and receives an id_token and access_token for the back-end web API.
Now, we don't want the SPA to do access control decision based on the id_token received within the SPA app.
Instead, the SPA sends the access_token to the back-end web API to access it, and now we want back-end web API to make an access control decision based on the roles claim found in the id_token, but which the back-end does not receive from the SPA.
The question is, is it possible for the back-end web API to send received access_token to Azure AD token endpoint and receive the relevant id_token for the user so that the back-end web API receives an id_token containing the roles claims for the user, in order to make an access control decision?
There are a couple issues with the approach as you describe it:
The app roles would be defined on the native client application (the SPA). Though you can technically define app roles in the manifest, you'll notice the Azure portal won't let you assign users or groups to a native client app. (Which sort of makes sense, because, as you've rightly said, you don't want to do any access control in the native client app.)
You can't do what you've described (exchange an access_token intended for one audience, for an id_token intended for a different audience). There are some variants of token exchange which you can do, but none of them would help you in this situation.
Instead, what you should do is define the app roles on the web API. Then, assign the users to the corresponding app role for the web API. When these users sign in to the SPA, and the SPA gets an access token on their behalf to the web API, you'll notice the access token will contain the roles claim, populated with the appropriate values.
Summarizing:
Under App registrations for the web API, define your appRoles in the app manifest (or on the Application object directly, using (for example) Azure AD PowerShell).
Under Enterprise apps for the web API, assign users and/or groups to their corresponding app roles, and choose whether or not app role assignment is required or not*. (Or do so directly on the ServicePrincipal object.)
Under App registrations for the SPA (the Application object), add the web API as a required permission.
*If you choose to require app role assignment for the web API (under Enterprise apps > Properties), the SPA will not be able to get an access token for users who are not assigned to an app role for the web API. If you choose not to require app role assignment , users who are not assigned an app role will be able to sign in to SPA and the SPA will be able to get an access token on their behalf for the web API, but the access token will not contain a roles claim.
We have our own existing we portal in ASP.NET MVC, now our one of the customer do not want to use our portal as separate tool, instead they want to consume our feature via WEB API and consume it on their side.
Now I want to implement authentication and authorization in web API, I did google to find my question's answer, but didn't get it.
I am confused in below points.
Is it best choice to OWIN the default implementation which Microsoft provide? or some custom implementation?
What are the advantage and disadvantage to use OWIN in terms of security?
When to Use JWT (Json Web token) and OWIN?
Or any other implementation which help to create more secured web API?
Looking for all expert's valuable to input to help me to decide.
I implemented something similar. This is how we work: we have our application (MVC app) which permits us to login. Logging in uses a separate mvc project (our STS) which handles all user authentication. When our login and password is posted correctly, we generate a JWT which is returned to the MVC app. Back on the application side, we decode our token and build up the claims in it in an asp.net application cookie.
We also have a separate project containing our WebApi REST methods. Those can only be called by using the JWT generated by our STS. We elaborated this more with a custom attribute so we can set permissions on specific permission or role claims that are in the token.
For creating all of this, i was helped very much using these series of articles: http://bitoftech.net/2014/10/27/json-web-token-asp-net-web-api-2-jwt-owin-authorization-server/
In terms of architecture this is in my opinion 'how it should be' but i am not an expert in this.
So summary:
Web Application - application cookie to authenticate/authorize
Calling WebApi Rest methods - using the JWT to authenticate/authorize
Separate STS which takes in POSTS to authenticate and generate JWTs