OIDC Acess JWT access tokens contain "allowed web origins" by default

[Olaf Heudecker]

Dear All,

TLDR:

KC standard setup sets OIDC Access JWT tokens with web-origins attributes. That is insecure and challenges scaling. Can we safely remove it?

Details:

I am wondering why this set up is automatically active in Keycloak Clients coming for the Client Scopes -> "web-origins" scope and the mapper called "allowed web origins".

It appears to me to be a security issue to increase the risk of attacks with exposed tokens if they contain the origins which might be able to use the token.

Besides the issue with exposing the usage options, I have a problem with token size in cases many redirectURIs are defined.

In my research I have not found much of a standardized list of attributes for OIDC Access JWT Tokens (besides iss, exp, iat, ...) but web-origins seem not mentioned.

Are there any risks if we removed the mapper for web-origins in Access TOkens?

Thanks in advance for a response,

Olaf

[Olaf Heudecker]

I have a guess (based on a colleagues comment):
If I get a JWT Token with allowed-origins, I could hope that the listed sites will be able to respond to API calls from my browser without CORS errors, IFF the adapt their CORS Policies.
That means, I could set up an ecosystem of applciations that could safely interact using allowed-origins in the Token to manage CORS.

But wouldn't I, for security not leave that to the token, but to each services CORS definitions?

[C R]

Hi Olaf,

I fail to see the security concern with Web Origins. As matter of
fact, in combination with valid redirect URLs it's one a the few
protections for single page JS web apps (public clients). The
documentation (https://www.keycloak.org/docs/latest/server_admin/)
define this as follows:

"This option handles Cross-Origin Resource Sharing (CORS). If browser
JavaScript attempts an AJAX HTTP request to a server whose domain is
different from the one that the JavaScript code came from, the request
must use CORS. The server must handle CORS requests, otherwise the
browser will not display or allow the request to be processed. This
protocol protects against XSS, CSRF, and other JavaScript-based
attacks.

Domain URLs listed here are embedded within the access token sent to
the client application. The client application uses this information
to decide whether to allow a CORS request to be invoked on it. Only
Keycloak client adapters support this feature. See Securing
Applications and Services Guide for more information."

(to make the web origins the same as the valid redirect URLs) use "+".

C.

Le mer. 27 avr. 2022 à 17:15, Olaf Heudecker
<olaf.he...@gmail.com> a écrit :

> --
> You received this message because you are subscribed to the Google Groups "Keycloak User" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-use...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-user/0c6b69c8-60e7-459d-abdd-df5e45396597n%40googlegroups.com.

[Olaf Heudecker]

Dear C,

thanks for the answer and the background of the consideration.

I was mixing up concepts as the REdirectURIs and the allowed-Origins are only connected if the magic "+" is entered.

Nevertheless, it appeared to be to be an exposure of information like "you can use this token here" which is extremely likely to be helpful for a hacker in case of an exposed token.

He/she would know where to attack and could easily (as long as the token is valid) inspect the services used to attack.

Therefore I would rather control such an implict CORS setup via (CORS) service related applications connecting to the Keycloak API to retrieve the allowed origins or managing this on the server side manually.

That is, however, more effort therefore I can see the beauty of having the CORS list communicated by the token.

The other critical aspect is one of scaling. Tokens to be used as Bearer Tokens seem to be subjected to limits of header sizes (often only 4kB) and therefore large numbers of clients (in the Allowed Origins, often implicit from the REdirectURIs with the magic "+") can cause stability and scalability issues.

Sorry to pester you with these considerations, but be assured, that this discussion is rather important for our project.

Is this a regular use case, that service CORS setup is controlled by the Keycloak allowed origins settings?
Aren't there many use cases where token become too large due to these allowed origins?

Best regards,

Olaf Heudecker

[C R]

Hi Olaf,

Just my experience, other people may have a different one.

> Nevertheless, it appeared to be to be an exposure of information like "you can use this token here" which is extremely likely to be helpful for a hacker in case of an exposed token.
> He/she would know where to attack and could easily (as long as the token is valid) inspect the services used to attack.

This is public information. We are talking about public clients (no
client secret) where the URL can be easily read on the JS code. So,
it's a false sense of security. Furthermore, if a token is stolen it
will be used widely and on the first place on the one that issued it.

> Therefore I would rather control such an implict CORS setup via (CORS) service related applications connecting to the Keycloak API to retrieve the allowed origins or managing this on the server side manually.
> That is, however, more effort therefore I can see the beauty of having the CORS list communicated by the token.

You need to control CORS on the client en on the target (Keycloak).
Otherwise you're not talking about a public client that connects
directly but about a backend server (a confidential client). In that
case, weborigins don't apply.

> The other critical aspect is one of scaling. Tokens to be used as Bearer Tokens seem to be subjected to limits of header sizes (often only 4kB) and therefore large numbers of clients (in the Allowed Origins, often implicit from the REdirectURIs with the magic "+") can cause stability and scalability issues.

We haven't had issues with token size yet, but there are a fez
mechanisms if you need it:
- you can configure what's added to the identity token.
- for the access token, keep the default scopes limited (but a client
always get) and make the rest optional (the client needs to ask for
them).
- let applications query keycloak's endpoints out of band, eg, the
token or user endpoint for extra information.

Regards,

C.

> To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-user/dcbf9312-f12a-4db3-9f35-f9f9c9a06c90n%40googlegroups.com.

[Olaf Heudecker]

Dear C,

Status: clarified

Thanks for your patience and explanations! That helps me understand the perspective and considerations. 

Since I needed a bit of time to put this into context, I share my "insight" here in case you want to reuse the picture (assuming it is correct):

Token Size challenges:

Re size limits and scaling : 4k (a limit we encountered with Elastic Beanstalk php default servers and node servers) seem to be full rather quickly if a few longish urls are added ...
We have a development client with some 30 URLs of each about 80 something chars, that will already contribute to about 2.5k header size (without other information, and JWT "overhead" counted).