[keycloak-user] How do you handle authorization and authentication in Microservices?

[Sebastien Blanc]

Hi,

Have you considered using a RPT ?
https://www.keycloak.org/docs/latest/authorization_services/index.html#_service_rpt_overview

Basically it's an access token that contains also the authz permissions and
one permission could contains all the required roles   (
https://www.keycloak.org/docs/latest/authorization_services/index.html#_policy_rbac
)

Then, in your client you remove the client scope "roles" so that their are
not added to your token and you end up with a really small token. The
service receiving the RPT token will be able  to check "offline" if the
token has the permission (the service will retrieve at startup all the
permissions).



On Thu, Mar 21, 2019 at 1:15 PM Pål Fossmo <pal at sentinel.no> wrote:

> At my company, we are building an application on top of microservices. We
> are struggling with deciding how to handle authorization and
> authentication. We are thinking of going down the path where we use OpenId
> Connect to authenticate the users, but when it comes to authorization, we
> need some advice.
>
> Let me explain how to solution works: A user can have different roles in
> different departments, and the number of departments can exceed 200. In
> each department, the user can have multiple roles. We understand that the
> recommended way of handling roles is to put them in the token sent from the
> client to the server (JWT). But, we are worried that this will make the
> token payload too big. As far as I know, a browser can hold headers up to
> 5KB of data. In our case, this means around 50 departments with two roles
> (uncompressed).  The pros of doing it this way are that the user is
> authorized and authenticated when he/she enters the microservice. The cons
> are, as I mentioned, the large payload in the token.
>
> We are also looking at a different option where we keep the JWT to a
> minimum (userid and departmentid) and query Keycloak for the user rights on
> every request (maybe add some caching mechanism with a short lifespan).
> This approach will generate a lot of request to the authorization server.
>
> What I'm looking for is some advice/experience of how others have solved
> this. I'm happy to provide more information if needed.
>
> To make it easier for you to give your advice, here are a short
> description of the two choices:
> 1) Use JWT to handle authentication and authorization?
> 2) Keep JWT light and make requests to the authorization server in every
> microservice?
>
> Cheers,
> Paul
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>