While checking a few api calls in the open source code of keycloak, I can see that token is clearly visible in the developer tools of browser. Can someone not misuse it, even though the validility can be a few seconds ? For example, when I click on “clients tab”, all clients are displayed and a “clients” call is made as in below pic, but I can very clearly see the token and upon checking in “jwt.io”, I am able to get all the details associated with the token. Thats a huge issue. Can someone not take the same token and make api calls? Am I missing something here?
have cropped the entire token in below snip for obvious reasons,
Also in source code of keycloak, I can see access token being passed directly as bearer in header, because of which the token may be visible in the developer tools of a browser. For example this,
Don’t mention people directly who are not already involved in the discussion/thread. That’s annoying. People who are able to help and willing to help, will do so. Otherwise not.
Keycloak is >10 years old and has a broad community and is widely used. Do you really think, nobody would have seen such an obvious issue, if this would really be an issue? There are options to mitigate the security risks!
That’s the nature of most OAuth implementations, they are bearer tokens. When being used by public clients, or in cookies, they will be accessible to the client since you are at the decrypted end of things.
In the case of your own tokens, you can’t do anything more with it than you could do already while signed in. Unless you gave it to someone else to misuse. Same with most app session cookies that are unbound.
The more concerning part is when they get sent around in plain text HTTP header traces, etc. But that’s also why you make them as short lived as possible, properly scoped access, and ensure idle/max session and token times align with the risk of the service etc.
If you want to broadly avoid token hijacking then token binding (mTLS, DPoP), IP validation, or some other needs to be implemented to bind tokens to specific devices, clients, or connections.
Exchanging Bearer tokens in the header of a HTTPS request is a thing, exposing it to the Javascript code of a SPA (and to the code of all its dependencies) is another.
That’s the reason why it is considered safer to use an OAuth2 backend for frontend (BFF) to bridge between session-based security (between the front ends and the BFF) and Bearer-based security (between the BFF and OAuth2 resource servers). Of course, session cookies should be flagged as secure, same-site, and http-only. The BFF should also be protected against CSRF. In this configuration, the OAuth2 client is the BFF, and it can be confidential (it can keep a secret to call the token endpoint, which SPA and mobile applications can’t do).
This seems to be a fair question and a concern that might have been evolving the past few years. It seems that the industry is also not completely clear what the best practice should be. Should handling tokens be a responsibility of the browser(-clients)? In the current world we live in, i think the answer seems to be ‘no’. With any XSS issue, the contents of the tokenset could be compromised.
You can use DPoP (OAuth 2.0 Demonstrating Proof-of-Possession) [1].
DPoP defines a standard way to bind the access token to the OAuth client, improving security.
DPoP uses public/private keys to create a signed proof, which servers verify to confirm the request and client’s authenticity.