It's clear for me about users authorization in microservice architecture (API Gateway for handling auth, SSO, authorization microservice and so on).
Now i'm thinking about authorization request between microservices.
And there is one question - which options i have in case when i have not got a user?
For example - analytics service, which requests data from billing and builds complex reports. There is no user, but do i need authorize request from analytics service to billing?
I know that there can be endless tokens, but i think its not good idea.
What another options for authorization request between services?
In OAuth2 specification there is such thing called machine-to-machine token. Which is different than password credentials flow which is refering to your user authorization.
To create a machine-to-machine token you should implement a flow called client credentials flow. In this flow basically all services have a specific client id and client secret and with those you are making a call to your central oauth-server to get a token. As it is also required to configure client details in the central service you will have the authorization in between client calls in terms of which client could call which others. There is also configurations for the time to live for each token.
If you already have the OAuth2 setup on your side it might be easy to introduce this new flow. But if you don't to implement such a thing on your side with your own setup could be tricky. Please check https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2#grant-type-client-credentials
Related
I am currently developing using spring security oauth2.
Currently, the frontend is SPA, and it is developed as react that operates with client side redering.
My rest api has the spring security starters libraries. But I don't know how to use oauth2 flow provided by spring.
So my question is: Can I use spring security as IAM to protect my web and api?
Does spring security have the known oauth2 grants and how use them ?
Implicit grant
Client Credentials Grant
Password grant
Don't use implicit grant
It is not recommended to use the implicit flow (and some servers prohibit this flow entirely) due to the inherent risks of returning access tokens in an HTTP redirect without any confirmation that it has been received by the client.
source: https://oauth.net/2/grant-types/implicit/
With implicit grant, access token is returned immediately without an extra authorization code exchange step. This extra step is usually performed in your backend.
Web > token > Api
SPA frontend and its Rest Api is a very common approach, used since simple startups until big companies. The flow summarized is:
Your users will start the web application.
As they were not signed in before, you web app will show them a login screen (a page provided by the authorization server).
After authenticating, a consent form is showed to the user.
After user consent, the authorization server will send you an authorization code.
The web app will exchange this code for a token.
After getting back this token, the web app store it in the client(browser) and send it as a header when apis needs to be consumed.
Your private rest apis must validate if token of the web app (header) is valid by sending it to one endpoint of the authorization server
If token is valid, your api rest is allowed to respond to the web client. For instance a json with products, employes, some update of customer order details, etc
For this flow to work, you will need:
web spa with a hint of backend. Backend is required because you cannot have a proper user session in static solutions like apache or nginx.
authentication and authorization server: Known as identity and access management (IAM) or some third app which provide you the basic oauth2 endpoints to manage a proper security for your apps.
your apis: foo-api , bar-api, baz-api, etc
spring security
In the minimal scenario in which:
you will have only one web + one rest api, and nothing more in the future (mobiles, iot, etc)
you don't have an authentication/authorization server
you have a mix of functional apis (employee, products, etc) and its security (spring-security) in just one artifact
you don't need user session in your web
you don't need a logout feature
Flow could be reduced to:
Your users will start the web application.
As they were not signed in before, you web app will show them a login screen (a page provided by spring-security).
After authenticating, a consent form is showed to the user.
After user consent, the authorization server will send you an authorization code.
The web app will exchange this code for a token. Since your api is using Spring security, the token generation is covered.
After getting back this token, the web app store it in the client(browser) and send it as a header when apis needs to be consumed.
Your private rest apis must validate if token of the web app (header) is valid by sending it to one endpoint of the authorization server I think the spring security chain filters handle this.
If token is valid, your api rest is allowed to respond to the web client. For instance a json with products, employes, some update of customer order details, etc
Here some samples of token generation and protected endpoints with spring security. I will try to upload a ready to use sample:
https://www.freecodecamp.org/news/how-to-setup-jwt-authorization-and-authentication-in-spring/
IAM
If you will have more applications and complex scenarios in the future, I advice you to choose some open-source iam like:
Glewlwyd,Keycloak,OAuth.io,ORY Hydra,SimpleLogin,SSQ signon,
Commercial services like:
Auth0,Curity Identity Server,FusionAuth,Okta,Red Hat Single Sign-On,cidaas.
Or try to develop a new one using pure spring-security
Lectures
Some recommended answers with more oauth2 details:
https://stackoverflow.com/a/62123945/3957754
https://stackoverflow.com/a/62049409/3957754
https://stackoverflow.com/a/57351168/3957754
https://stackoverflow.com/a/63093136/3957754
https://stackoverflow.com/a/54621986/3957754
https://stackoverflow.com/a/63211493/3957754
I need to develop set of microservices (rest APIs) which is to be used by web and mobile client, the microservices are sitting behind API gateway, I've to integrate with SSO (using SAML) for user's authentication, I understand that SAML token to oAuth2 token conversion has to be done so that I can verify auth token at API gateway and handle authorization there itself, but the piece which is not clear to me is that who will take care of conversion of SAML token to oAuth2 token, is it IDP who provide this functionality out of box or do I need to built up something of my own?
One possible solution which I'm thinking of is
User (from web/mobile) sign in via SSO
Gets SAML response from IDP
Send that SAML response to server to generate Auth Token
Server gets request to generate auth token, looks for SAML response and validate it against IDP
If SAML response is valid then generate auth token and send it back to client
On subsequent API request from client the token is passed as header which API gateway validates
The thing is I'm bit reluctant to implement SAML and oAuth thingy myself and looking for some ready made solution but couldn't find any, can someone please suggest of any library solving this problem, thanks in advance.
It feels like your approach is correct - it is the role of the Authorization Server (AS) to deal with SAML login integration for you. Only configuration changes should be needed, though of course you need to use an AS that supports SAML integration.
Your UIs and APIs will not need to know anything about SAML and will just use OAuth tokens. There should be zero code changes needed.
Most companies use an off the shelf AS - eg from a low cost cloud provider. My Federated Logins Blog Post summarises the process of integrating an IDP. The walkthrough uses AWS Cognito as the AS - and the IDP could be a SAML one.
I maintain a microservice that sounds like it could help you - https://github.com/enterprise-oss/osso
Osso handles SAML configuration against a handful of IDP providers, normalizes payloads, and makes user resources available to you in an oauth 2.0 authorization code grant flow.
Osso mainly acts as an authentication server though - we don't currently have a way for your API gateway to verify an access token is (still) valid, but that would be pretty trivial for us to add, we'd be happy to consider it.
For example on the default jhipster UAA configuration we have:
clients.inMemory()
.withClient("web_app")
.scopes("openid")
.autoApprove(true)
.authorizedGrantTypes("implicit","refresh_token", "password",
"authorization_code")
.and()
.withClient(jHipsterProperties.getSecurity()
.getClientAuthorization().getClientId())
.secret(jHipsterProperties.getSecurity()
.getClientAuthorization().getClientSecret())
.scopes("web-app")
.autoApprove(true)
.authorizedGrantTypes("client_credentials");
So what does "authorizedGrantTypes" really means in practice? The first client "web_app" will have different types including refresh and so the second will be able to generate a token as client_credentials. What is the difference?
Another question, what is the purpose of the second client authentication which uses "client_credentials" ? Since this is disconnected from the real users stored. microservice to microservice communication? Looks bad if the configuration is deployed on spring cloud (client and secret hard coded configuration) to allow any external authentication via the gateway. How to prevent this?
OAuth 2.0 grant types are the different "ways" your client applications can obtain tokens.
There are a bunch of articles explaining it better, but here is a summary :
authorization_code is the "classic" OAuth 2.0 flow, where the user is asked for its consent through redirections. The client application is strongly authenticated because it has to send all its credentials (client_id+ client_secret + redirect_uri) before it can get a token.
implicit is almost the same as authorization_code, but for public clients (web apps or installed/mobile applications). The flow is almost the same from the user standpoint, but with weaker client authentication. The redirect_uri is the only security, as the client receives the access token through redirection + request parameters.
password is straight forward : the client application collects the user credentials, and sends both the user credentials (username+password) and its own credentials (client_id+client_secret) in exchange for a token. This flow mixes authorization with authentication, and should only be used when there is no other choice (i.e. your own installed/mobile application, where you don't want users to switch back and forth between native app and browser). You should never allow a third party to use this flow.
With all these flows, the user is asked for its permission, one way or another. The token given to the client allows it only to access that single user's data.
The client_credentials grant is different, as it does not involve a user. It is a drop in replacement for HTTP Basic.
Instead of sending a username (client_id) + password (client_secret) for every request, your client sends its credentials in exchange for a token.
It is used in server-to-server communications, where you want to know "which application is calling" by giving it distinct credentials, but you don't tie its authorization with a specific user.
Some examples :
a command line application (batch) or worker process consuming secured services. This kind of application probably processes a bunch of user data at once, and it cannot request each user's consent. The service called has to know "who" is calling in order to allow the client application to access anything.
a third party / external client of your API wants to know informations that are not linked to user data (for example : usage stats, quotas, billing...)
a third party / external client with special privileges who can access all your users' data
Note : In service to service communication, you should relay the token received from the outside instead of having each intermediate application request its own token.
How API Gateway and Micro services works.
Could anyone explain the basic flow of Micro service architecture with Gateway. I couldn't find the proper answer.
Say we have auth server and customer micro service running on separate instances and in front of all the services we have an API gateway.
My question is.
when user try to log in using username and password, the API gateway call auth server and return the access token to user.
Then user trying to access the specific url (/customers - customer micro service) that is running on separate instance.
what API Gateway do ?
validate the token with auth server and get the user id and pass the request to customer service with the user id ?
OR
validate the token and pass the request to customer microservice with the access token ? and customer microservice responsible is to the check the user id (Make an HTTP call to auth server) ?
I think that the most common approach is to use API gateway also as a security gateway, which means that API gateway is responsible for SSL termination and token validation. If token validation is successfully you can put user ID or user API key as a header and forward the request to microservice. Moreover you may also decide to perform not only authentication but also authorisation on the API gateway (usually with help of API management solutions).
Regarding your option #2 - I see no point in validating token 2 times. Best practise is to perform security validations on the edge, because in case of failed validation you use less resources (reject earlier)
To Answer your question , it is close to option #2 that you have mentioned . The API gateway will generally check the validity of the authentication token and then pass over the request to your micro-service . However you need to decide at design time if your micro-service will also do another level of verification of the token.
Please do note that the API gateway will not be enforcing Authorization , the authorization is something that your micro-service will have to enforce.
So I currently have this POC that I'm tinkering right now. I was thinking if it was possible that I can implement a Spring oAuth2 with JWT with a Authorization Server and a Resource Server both in different projects?
Flow goes like this User gets a token or passes through the Authorization Server and as long as he has the token and it's not expired he can make requests on the resource server.
I think that is the usual way to implement that. You have one authorization service providing tokens, either itself is backed by a database containing user information or maybe is asking another user service if the credentials are valid. The returned tokens can be used to make authorized request against the resource service(s).
Maybe take a look at the grant flow here.