I am using Keycloak 17.0 with
keycloak.profile.feature.admin_fine_grained_authz=enabled
keycloak.profile.feature.token_exchange=enabled
The issue: I need to provide refresh token for a client on behalf of already authenticated confidential service account client. I need something very close to internal to internal token exchange like it's described here. The only thing is that I need to make a token exchange call without subject_token parameter. Is it possible to have a client that will provide tokens for another internal clients without their authentication/tokens?
Related
I need to build a REST API that will be used by one private SPA web application. The problem is that the REST API must be on a different server than the SPA, so it must allow CORS. For two layers of security, the API can require Basic Authentication over SSL plus check for the correct client IP address.
It will not be possible to have a user login process for the API, since it is a service used by the SPA. The user is already logged into the client that hosts the SPA. I will not have access to anything other than the user's ID, and the REST API will have no way to validate this user ID.
Because the user is logged into the client's server, the API can be restricted to requests from the SPA's IP address, but that still potentially could allow anyone on that server to use the API other than the SPA.
Is this adequate protection?
I am considering adding a third layer of protection in the way of an access token, but this would be also fairly simple to uncover. If you know the basic authentication information (easily obtainable) and your IP address matches the expected client IP, then you are able to call the API to get an access token.
Also, with an access token comes the complexity of dealing with expired tokens.
Is it impossible to completely secure an API that requires a web-based client?
How many layers of security are enough?
I'm googling since long and i'm bit confused now should i create Custom iDP or Authentication provider in Keycloak.
Below is my requirements.
I have multiple clients and each client having login API which also returns JWT token on successful login so what business needs is that when user try to login i want keycloack to consume client API to Authenticate User and once user successfully authenticated by Client API Keycloack should generate token for further operations.
One more problem is can i use same token return from client as Keycloack token because there are some apis on client side which decode token and use some info from token.
Please suggest and i'm bit stressed to looking for different solution and couldn't help. I will be grateful if you can share sample code with it.
What do you mean by "I have multiple clients and each client having login API" (does that mean different endpoints secured by different realms?? I supose that's not what you want).
What you mention here:
"what business needs is that when user try to login i want keycloack to consume client API to Authenticate User and once user successfully authenticated by Client API Keycloack should generate token for further operations."
that is indeed the standard behaviour of Keycloak, why do you need a custom Authentication (user federated Authentication/ identity Provider)? You haven't made clear from the description of your problem, why do you need a custom Identity Provider SPI /custom Authentication federation? If you really need an Authentication SPI, please read chapter 8 from here:
https://www.keycloak.org/docs/latest/server_development/index.html#_auth_spi
that's the best documentation on that topic. Are you authenticating against a custom Auth service of your company that doesn't support openid connect? If not, then you don't need a custom Authentication SPI.
regarding:
"can i use same token return from client as Keycloack token because there are some apis on client side which decode token and use some info from token."
I don't know exactly what you mean there, but depending on your client adapter there are slight variations on the way you get/extract a bearer token & secure your endpoints in general. Plase read chapter 3.1 from here: https://www.keycloak.org/docs/latest/securing_apps/index.html#_client_registration
There you'll find base implementations/suggestions for the different client adapters, or at least should move you forward in your search.
Hope it helps.
I am in the process of implementing IdentityServer3 in our company but I have hit a blank around how to handle client to client authorization and would appreciate any pointer in the right direction.
This is a summary of our requirements:
We have multiple web site clients that our users access. These are configured using the AuthorizationCode flow. Lets call these WebSiteClientA, WebSiteClientB.
We have multiple WebAPI clients as back end services that could be accessed by either a client (WebSiteClientA, WebSiteClientB) or a user (who has access to WebSiteClientA or WebSiteClientB). Lets call this WebAPIClientA.
Note: Our company owns the users identity as well as all clients.
Initially I though we could configure WebAPIClientA using the ClientCredentials flow. Then WebSiteClientA \ WebSiteClientB would be configured with the client credentials for WebAPIClientA and could generate an access token when it required access to WebAPIClientA, or alternatively generate an access token with limited scopes and hand this access token to the user so the user can access WebAPIClientA directly from the client side.
This would meet almost all our our requirements except 1 big one, we also want to be able to manage what scopes a client has access to for another client and with the approach of using the ClientCredentials flow anyone with the client credentials would be able to generate access tokens for all scopes under that client. ie WebSiteClientA should be able to generate an access token for WebAPIClientA with read & write scopes but WebSiteClientB should only be able to generate an access token for WebAPIClientA with the read scope.
In my mind the client\identity server conversation would be:
WebSiteClientA makes a request to the identity server for an access token to WebAPIClientA for scope X and provides the client secret for WebSiteClientA. The identity server then says yes, you are WebSiteClientA and we can see from our records you have access to WebAPIClientA with scope X, here is an access token.
Is this possible or am I looking at this in the completely wrong way and there is maybe a better approach to meeting the requirements?
It sounds like you're talking about two things.
The first is that in the APIs you need the user's id. To obtain the user id you have a decision if you want to build a trusted subsystem, or if you don't want a trusted subsystem (in the sense that your APIs trust or don't trust the MVC client to pass along the user's identifier). If you do a trusted subsystem, then the client credentials flow from the MVC client to the API is fine. If you don't want a trusted subsystem, then you need the MVC client to obtain an access token for the user (via implicit or hybrid flow).
The second issue you're asking about is if you can control the scopes each client is allowed to request, and you can via the AllowedScopes configuration property (or whatever it's called) on the client configuration. This setting is orthogonal to the first issue mentioned above.
I have Oauth2 implemented in my application to protect API calls.
My Oauth and resource server are on two separate physical boxes(but on same network). For each call on resource server it needs to call Oauth server for Oauthtoken validation.
I have millions of request coming to my resource server in a day.
Currently to validate Oauth token I am using rest call from resource Server to Oauth Server.
Is there a way to make this faster as each and every call needs to be redirected to Oauth server? Can webSockets solve this problem?
If you don't need to revoke individual access tokens, you can use stateless (JSON Web Token) JWT tokens. JWTs don't need to be validated on the authorization server. As long as the JWT token is signed by the authorization server (asymmetric cryptography), you can validate the token on the resource server itself using the authorization server's public key.
This makes for fast authorization (since it skips a server-to-server round trip) at the cost of easy revocability.
Note: you can also use a shared secret (symmetric cryptography) but then you need to make sure all the interested parties have the shared secret (and keep it secret).
Look into spring-security-jwt and https://jwt.io/
I have a scenario where a user has logged into to a web application (authenticated with OpenID Connect) and then needs to access data from a separate REST service.
The REST service needs to determine whether or not the user has permission to access the requested data, but if the user does have permission, then it should grant authorization to the web application without requiring the user to interact with the UI.
Essentially, what I need is a two-legged OAuth solution where the client/relying party is fully trusted but the user, who's already been authenticated, is not.
Going in, I assumed that OAuth could accommodate these requirements, but none of the grant types seem to match the requirements:
Authorization Code is the opposite of what I need, as the user is pretty much automatically trusted but the client is not, requiring that the user grant access to the client via a web form.
Client Credentials trusts the client (which is what I need) but does not give the service an opportunity to determine if the user has permission to the resource (user auth tokens are not passed to the service, making all requests essentially "anonymous").
ROPC (Resource Owner Password Credentials) would appear to be the only option, but requires the web application to know and possibly store the users' login credentials (which is untenable).
Is this a gap in OAuth? Or am I misunderstanding these grant types? If OAuth can't support this scenario, is there another widely adopted open standard that I've missed?
Of note: I only own/control the web application, while the customers (all of which are businesses) own/control both the authentication servers and the REST services. Therefore, a shared, non-proprietary standard is necessary so that our customers will know how to configure their services (IBM, Microsoft, whatever) and so that I'll know how to pass along any authentication tokens, etc.
I think this is possible using normal OAuth2 flows. You have your web application use the code authorization grant to get a token to call the API on behalf of the user.
Your web application makes the call to the API attaching the JWT token in the Authorization header. If the REST service determines the user does not have permission to access the resource, it returns a 401 Unauthorized HTTP response code.
Your web application handles the 401 response by going back to the authorization server and using the client credentials grant to get an access token to call the REST API on behalf of the client itself.
As both grants allow you to get a refresh token, you should be able to switch between access tokens easily.
If there is no trust relationship between the web application and the REST service, there's no way around using the Authorization Code grant since the user needs to be involved anyhow to allow the web application to make the call on behalf of the user.
If there is a trust relationship between web application and REST service you should be able to use the regular OpenID Connect flow to get an access token to the web application at login time that can also be used in calls towards the REST service.
You may pass on the user information as part of a JWT (i.e. a structured) access token that is signed by the web application itself or the OP; that would be OAuth 2.0 compliant. See https://www.rfc-editor.org/rfc/rfc6749#section-1.4 and May an OAuth 2.0 access token be a JWT?.