I have an eco system that the gateway and federated services live. The problem is when the gateway starts it validates the services - to do this it needs to be authorised.
When a client is querying via federation gateway they supply a bearer token.
In both instances the request header authorization field is used.
I've read and reread the docs but I am unable to achieve this using different tokens for different actions.
Anyone any ideas or links to relevant docs?
Cheers
Rereading for the Xth time the solution is with the "buildService".
It is only called once for each implementing service. You can extend it and add whatever headers you need.
See here for docs + example:
enter link description here
Related
There is a lot of good content on the internet that explains how to secure a Spring API with Keycloak: Create a Client that represents the API Service in Keycloak and use a link like the one below to get the access and refresh token:
<Domain>/auth/realms/<realm>/protocol/openid-connect/auth/{some parameters}
This yields both tokens. So far so good.
Now, however, I am not sure how the flow for the frontend accessing the API should look like.
Should the frontend directly access this endpoint and, therefore, obtain the access and refresh token? That would mean that the API can only have the access-type public because there is no way to store the client (the API) secret securely.
Or should there be a third server that somehow stores the refresh token for each user, that the user can call if his access token is no longer valid. This server would then use the client's refresh token (and the client secret that could be stored securely, since it would be in the backend) to get a new access token from Keycloak and would forward it to the user.
I guess the main question that I am asking is, whether the client/user should get the refresh token.
If one needs to implement a logic according to the second option, I would be interested in a link or description of how something like this can be done in Spring.
I think, in either case you need to use the Authorization Code Flow. The implicit flow, which was recommended for SPAs (frontends without a backend server) in former versions of OAuth2 must not be used anymore.
The best option is to have a backend server, so the user retrieves the auth code via redirection and the backend server exchanges this auth code with the access and refresh tokens (and keep them without forwarding them to the frontend).
If there is no backend in place and your frontend needs to retrieve and hold the tokens directly, I would recommend to use the Authorization Code Flow with a public client and the PKCE extension (which - put simply - ensures that the entity asking for the auth code is the same as the entity asking for the tokens and that the auth code was not stolen and used by a foreign entity). There are several sources with more detailed explanations, which might help you, for example: https://auth0.com/docs/flows/authorization-code-flow-with-proof-key-for-code-exchange-pkce
Hope this helps you with your architectural considerations.
I have developed a set of microservices (resource servers) using Spring Boot 1.5.x + OAuth2 with JWT. Right now each microservice is protected using Spring Security i.e. JWT access token is verified at individual resource server level. API Gateway does not have spring security in place, so it just routes the requests to appropriate server and propagates the authentication headers to downstream services.
I wanted to know if there are any disadvantages of this setup compared to the one where AccessToken is verified at API gateway level only. Or is it just a matter of opinion? Doesn't keeping security at API Gateway level breaks principle of loose coupling, because each microservice may better understand the role of a given user in its own context?
API management can do a small check on your JWT (fail early), BUT your microservices are the only one that can really manage all the security stuff !
If you set security only on api management it means that someone that can access your network will be able to push request to your API unauthenticated.
You will not be able to log who do what. And finally, if you need to set some kind of ACL, it will not be possible (When you ask to list orders, you can only list YOUR order).
Perhaps you will think of decoding your JWT on the api management layers and push a header with user name to your backend to prevent all the thing I spoke about above, but I think it is not really a good practice.
First, access to network will means I'm able to be anybody. Then JWT is much more than just a username. For instance, perhaps you use scope on your authentication layers. ( scope read orders / scope modify orders / scope delete orders). This is useful to restrict what an application can do (either at client_id level) or what a user accept to give to the application ( scope share email ...).
For this JWT on the backoffice is mandatory.
Ok you can do like username and extract data on api management and put specific headers to call backend, but really ? why do specific stuff ? oauth2 with JWT can do this for you.
Well this is an interesting question. In our team we discussed about this topic a lot. Basically you have some parameters affecting the individual answer to this question. But you should always decode and verify granted tokens on the microservice level, too. Because they contain relevant information for authentication and in some cases even for authorization. If your microservices run in a enclosed environment (e.g. on enclosed Kubernetes cluster, where only the API-Gateway is available to the outside) you could use this "mixed" solution.
You can really consider just to verify the AccessToken at the API-Gateway and let the other microservices rely on the API Gateway. The API Gateway could than exchange the AccessToken into another AuthToken, only valid in the microservice-context. This new generated AuthToken can for example contain more sensitive application-bound information, because it is not exposed to the client. The Client gets only a so called opaque token. See https://medium.com/tech-tajawal/microservice-authentication-and-authorization-solutions-e0e5e74b248a
I was reading up about API Gateways (Kong) and I wanted to integrate it into my application. Every tutorial I've seen creates consumers for the services using Kong API or through a dashboard like Konga. I already have a user registration/auth service. How can the API Gateway replace that ? How should the user registration be changed so that Kong knows about it ? And how would login work because In all the examples I've seen the ApiKeys or JWT secrets are created in Kong ? Can any body shed some light on how this works in practice ?
In my opinion Kong is not supposed to replace a user registry / authentication service. However, it can help you enforce authentication.
There are several options of securing your APIs against unauthorized access. These include:
API key: this type is used with the key-auth plugin and is not intended for authenticating users (meaning natural persons) but consumers (meaning other systems).
JWT tokens: this type is used with the jwt plugin and is suitable for user authentication. Kong is responsible for validating the JWT tokens (by checking the signature and expiry of the self contained token). You can of course do further checks either with custom Kong plugins or within your upstream service.
So I think you shouldn't think of Kong as a replacement for your user service, but as a complement/addition which helps you enforcing security policies even before the request reaches your upstream service.
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.
I am currently developing an API that I plan to secure using oauth2.
I have chosen: https://github.com/lucadegasperi/oauth2-server-laravel/
I have managed to secure the endpoint (using before=>oauth in my api routes) by following the installation guide but I am at a loss as to how am I gonna be able to authenticate and access the endpoint.
I do understand that you will first need to request an access_token by sending a client_id and client_secret but what I don't get is where do I set those on the oauth server?
I see the oauth controller has endpoints for these like:
http://somedomain.com/oauth/authorize
http://somedomain.com/oauth/access_token
But I am clueless with what to do with them. I only managed to arrive at the conclusion that it needs a client_id, client_secret, and stuff about scopes.
Where can I set these values for the api client to use?
Thank you for your help in advance.
I don't know Laravel, but in general, the authorization endpoint (in your case, http://somedomain.com/oauth/authorize) behaves as described in RFC 6749.
The specification defines four flows. If you use Authorization Code Flow among the flows, you should access the authorization endpoint with the following request parameters.
response_type=code (required)
client_id={your-client-id} (required)
scope={space-delimited-scope-names} (optional)
redirect_uri={your-redirect-uri} (conditionally optional)
state={any-arbitrary-string} (optional)
For example,
http://somedomain.com/oauth/authorize?response_type=code&client_id=your-client-id&scope=profile+email
The authorization endpoint generates an authorization code and returns it to your browser.
The next step is to access the token endpoint (in your case, http://somedomain.com/oauth/access_token) with the authorization code which has been issued from the authorization endpoint. Like this,
POST
http://somedomain.com/oauth/access_token?grant_type=authorization_code&code=issued-authorization-code&client_id=your-client-id&client_secret=your-client-secret
Anyway, I recommend you read RFC 6749.