We are building a web application in microservices architecture.
We have a service that handles the authorization (i.e user's privileges, access credentials, roles etc...) and we are considering how to pass on these credentials in the system.
We have 2 option:
1. Sign those credentials in the gateway (auth and proxy service) using JWT and pass on all the information so every service could verify it (with its public key) and read the user's info.
2. Every service should make a request to the authorization service for querying the user's access on every action.
We are having difficulties on deciding which way is better in terms of high cohesion and loose coupling and of course making it easy for service development.
You have some other options: instead of reinventing the wheel, you can use an OAuth 2.0 identity provider/broker out of the box.
Keycloak is a free open source identity provider and broker that provides all these functionalities.
Auth0 is a managed commercial service that provides all these functionalities too.
And I'm sure there are many other services exist for OAuth 2.0 protocol.
As for your 2 options:
You can extend the JWT with your custom authorisation claims (roles or permissions) and since the JWT will be signed, then it is safe to assume the data is correct by your service. Give that the JWT is a short lived token that need to renew every few minutes.
Related
I have to design an IAM solution for a NodeJS microservice using Auth0. Objective is to allow third party mobile application users to access this microservice.
I understand OAuth and OpenID connect solution and one simple solution is third party application accesses APIs as a client using client credentials workflow.
Solution I have to design is allowing users to login and authenticate using their Enterprise IdP connected to our Auth0 Server. So that we can implement authorization and access control at user level.
At the same time customer application needs to be kept agnostic of Auth0 service.
What I mean by it is client should not be required to add any logic in their application for accommodating our Auth0 domain like we have in first party React application. user once logged in to customer application should get access to our API also by using SSO capability. I have read some documents about configuring customer IdP with our Auth0 server acting as a SAML SP. Still I could not understand hows of it and will Auth0 create an OAuth access token in this scenario.
I realise this requires an app to intermediate between customer's mobile app and our API service. Still, I am not able to understand data flow and communication between various components.
Also, I am not sure it is a common situation or requirement? If it is is there any technical term for it? This not seem like a standard B2B scenario.
have to design an IAM solution .. , I am not able to understand data flow and communication between various components ..
Before answering, the answer will points the asked specific questions, may not fit al your needs. SO is not really intended for writing tutorials or searching the documentation. Implementing an IdP (effecively a security module), one needs to do his homework and learn the details.
Maybe using an ready / out of box solution could be interesting. Using an open source IAM such as KeyCloak, WSO2IS could be a quick start. Or cloud services such as AWS Cognito, IBM AppId, Azure AD, .. could be a feasible solution too
a client using client credentials workflow .. access toked received by our API should be for user logged in
The client credentials grant is intended to authenticate only applications. That's it.
To authenticate users, other grant type is needed. For the user authentication the most common option is the authorization code or the implicit grant. The implicit grant is has its weaknesses and is being replaced by the code grant with PKCE (just search it).
End requirement is users of 3rd-party application not required to login again while 3rd-party application fetches data from our API .. Configuring their IdP (most probably Active directory) and our Auth0 servers for the same is all I need to understand
I see most common two options in use:
1. federated SSO authentication
This is the most commonly used option. The external (3rd party) IdP is configured as a "trusted" federated IdP. You often see the scenario when you have a service provider allowing to login with other IdP, often social networks (FB, Google, ...)
The login flow is as follows:
The client authorizes with the provider's (yours) IdP (let's call it IdP1).
IdP1 now acts as as Service Provider with IdP2 (IdP of the partner) and asks for the authorization (redirects the user to the IdP2).
User is authenticated and authorized with IdP2. If the user is already authenticated, the IdP2 doesn't need to ask the user's credentials again, this is how SSO works on this level
IdP2 returns to IdP1 (acting as a service provider).
IdP1 reads the user information (using the id_token, userinfo service - assuming using the OAuth2/OIDC protocol all the time there are other protocols too) and builds its own the user-level token. It may or may not create a local user (it is called user provisioning).
IdP1 returns to the client and the client can request a user-level token.
Then the client can call the API services with the token trusted by the API provider.
2. Assertion Framework for OAuth Authorization Grants
This option is built on top of the Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants, it is an optional extension of the OAuth2 protocol. I call this a token swap service
Basically the token service could validate the access or ID token of a trusted (partner) IdP and issue its own token based on the provided user information.
As you see there are a lot of information and to build a secure solution you ned to make sure that all steps are properly secured (signature, expiration, issuer, validity, audience, subject domain, .. are validated). Disclaimer - as my job we implement IAM/IDM solutions and a lot can get wrong if shortcuts are taken. So you may really consider using an out of box and proven solution.
I have two web applications app.domain1.com which is a SPA with his own API on api.domain1.com and app.domain2.com) with each have their own authentication system and user accounts
and I need to authenticate the user from app.domain1.com from app.domain2.com. The goal is to simplify switching from one app to another without requiring the user to log into each application by re-entering their password. I'm the owner of one app only so It's not possible to put them behind a reverse proxy or so.
Example :
app.domain2.com redirect to app.domain1.com/connect/{JWT} -> app.domain1.com SPA extract the JWT and send it via ajax to api.domain1.com for validation and login.
I have looking for OAuth2 and OpenID Connect for these but OAuth2 is more about delegation of resource access than authentication and OpenID Connect needs an Identity Provider which seems incompatible with my use case where each app has his own authentication mecanism and where I could not add a central authentication server.
Ideally, I'd like to adhere to a standard protocol.
I thought I could expose an endpoint GET /connect/{JWT} on each app.
The JWT could contains an email which could identify the user account, app.domain1.com and app.domain2.com could then share the secret for validating the JWT has not be tampered
and could have a short validity duration.
This endpoint validate the JWT, verify if a user match the email inside the JWT and log the user in.
I'm not sure about the security considerations with these process and if there is any other options ?
Thx for your help.
In my opinion you should go with OIDC. That protocol is designed exactly for the feature you described here. You can have one of the apps act as the IdP, and the other will be a Relying Party. It depends on which technology you use for your apps, but in some languages there are libraries which will turn your app into an IdP.
You can think of some generic protocol to make that federated login work, but you will be better off using standards. This way you won't have to wonder what are the security implications for your solution - you have security considerations for OIDC described in the spec itself.
I'm building a SPA (angular) with a back-end api (asp.net core), both are build and belong to the same party.
I would like to use jwt authentication instead of cookie based authentication, because both sides - the back-end and the front-end spa - are owned by the same party I'm thinking to use the OAuth Resource Owner Password Grant flow and there shouldn't be any problem exposing the users credentials to the web app.
After searching on the web, I see a lot that it's not recommended to use this flow, but why should I implement any OpenId Connect flow with a redirection to the auth server if the web client belongs to same party of the api and the auth server?
The problem in your case is not so much in exposing the credentials to the Client since as you mention, all components in the flow are controlled by the same party.
Yet there are advantages to redirection as doing so separates the authentication method and means from the Client itself. And that enables e.g.:
a change of authentication mechanism or an upgrade to multi-factor (or some other advanced form of) authentication without impacting the Client(s)
SSO across different web applications
granular per-Client permissions
easy access revocation without having to change the user's password
less confusion for end-users as to which applications(s)/Client(s) they can trust with their credentials
I have a web service that acts as a OAuth 1.0a provider. Web applications go through the OAuth 1 workflow to gain access to user resources. So far so good.
The client web application has the need to communicate with the service for other needs, to exchange private data NOT linked to a particular user/resource owner. For that, a good idea seems to use OAuth2, in particular Client Credentials Grant (4.4)(which was designed exactly for this).
From a "confidential client" (and a web application falls into this category, according to the OAuth specs) you can directly authenticate your client and get an access token.
EDIT: of course, the kind of web application I am talking about is html+javascript BUT authentication and communication with the provider/web service happens entirely server-side. Credentials (client secret, keys, etc.) are all stored on (and never leave) the server.
According to the specs, authentication can happen with "username+password" (client password with HTTP Basic authentication scheme) or "other authorization methods".
I was not able to find any clue of what these "other authorization methods" may be.
Since we use private/public key pairs for OAuth1, can we use them for this task too?
The specs seem very liberal (and very vague!) on this point.
I would like something that is supported by the various libraries, so that a 3rd party client can implement it easily using standard libraries (like DotNetOpenAuth for example). If needed, it is reasonable to assume that some coding needs to be done for the custom method, as long as it can accommodate existing libraries (plugin?)
Is there anything "standard" or easily usable other than HTTP Basic, for OAuth 2 authentication?
If by web application you mean a JavaScript and HTML app that runs in the client browser and needs to make secure requests to your service, that is not a "confidential client". You cannot store secrets in a browser based app, as they will be visible to all.
If by web application you mean a server-side application that needs to make server to server requests, that is a "confidential client" because the executing code and secrets are not available to public scrutiny.
I interpret the "other authentication methods" to mean any authentication scheme that is customary over http (or https) that can be completed in one request. Client certificate authentication using TLS might also fall into this bucket. I think the main part of the OAuth2 4.4 Client Credentials Grant is that the client app presents credentials directly to the OAuth token service via existing authentication methods. The example uses HTTP Basic authentication, but that's just one example.
Client credentials grant differs from the resource owner credentials grant (4.3) primarily in that the resource owner grant presents the user credentials in the body of the http request instead of in the Authorization header. It would be difficult to use other authorization methods with resource owner grant.
The greatest caveat in using other authentication methods with the Client Credentials Grant is that support for anything other than HTTP Basic auth by OAuth2 client libraries will likely be spotty at best. Even if your use of digest or client cert auth with Client Credentials is within the OAuth2 spec, I'm doubtful that existing OAuth2 client libs will have built-in support for your particular permutation. See if you can find examples of client credentials grant using anything other than HTTP Basic auth by some of the big players such as Google or Yahoo. Things used there are more likely to be supported by OAuth client libs (especially the libs they ship!).
If you own both ends of the connection, this doesn't really matter. You can do whatever you want and find a client lib that will let you tweak or tailor the request to fit your needs.
If you want arbitrary clients to connect to your service using client credentials grant, you should plan on providing documentation and sample code of how clients should present the credentials you require. Off the shelf OAuth2 client libs probably won't provide automatic support for your scheme.
I have several Silverlight, WP7 and ASP.NET MVC client applications Most allow anonymous access to the application but secure various features based on a user's credentials when logged in. All of the clients use a common back-end service application for data access and business processing which require the user's credentials for authentication and authorization.
We currently use Forms Authentication in all client applications and I'd like to migrate our architecture to use federated identity and a claims-based model. Passive federation is not an option.
I am looking for the following flow:
The user triggers the login dialog, enters their username and
password then clicks "OK".
Behind-the-scenes, the application calls an active STS service in
our existing service application for authentication.
The service is actually a federated STS and passes the call through
to the (active) IP_STS which may or may not be ADFS.
When the IP returns the token to the FP, the FP modifies the token
with additional claims from the server data store before returning
the token to the client application.
The client application maintains the token in memory for
authorization checks (in Thread.CurrentPrincipal, for example).
The client also passes the token when making requests to other
service operations in our service application.
These service operations will use the token to
authenticate/authorize the request.
This is a very different use-case from any of the articles and samples I've been able to locate. Can anyone provide some guidance and/or point me in the right direction?
It is my understanding from Dominic Baier that WIF doesn't currently support the approach we are taking. We've taken his suggestion and created our own custom STS that moderates authentication using the Provider model.
Unfortunately, the farther we got into this, the more we realized that WIF isn't flexible enough to satisfy our needs at this point. We stuck with the custom STS approach but are using our own transport and credentialling rather than the WIF tooling. Hopefully a future release will give us what we want.