On 5/20/2014 10:07 AM, Bill Burke wrote:
On 5/20/2014 9:33 AM, Stian Thorgersen wrote:
> I like the idea of not having to specify the web-origins, but I wonder if there are
use-cases for having web-origins that can't be calculated from the redirect-uris.
I just can't see a case for this. Let's just let users tell us we need
this control. Right now, the web origin is always set to the
protocol://hostname of the application or oauth client.
> Also, the web-origins is used by Keycloak's own endpoints. In this case
"Cross-Origin Tokens" doesn't make sense.
You're talking about the Account Service correct? Well, I'm changing
that! :) How you implemented CORS support for the Account Service is
not how web-origins were intended to be used.
Tokens are created for a specific client (app or oauth). The
web-origins for that issuedFor client are stuffed into the token created
specifically for that client. Basically, its saying this token is
allowed to come from this set of origins.
What Web-Origins are not origin permissions for that application/client.
When you specify a web origin for the Account Service (or any other
application) in the admin console, this is not origins that are allowed
to call the account service! But instead, the origins allowed for token
requests made from tokens created for the Account Service. Am I making
Ugh, let me reword last paragraph:
Web-origin setting is not a set of origin permissions for an
applicatin/client. For example, the account service's web-origin
setting is not the origins that are allowed to call the account service!
Tokens are always created for a specific client (issuedFor). The
client's web origin setting is just information that is stuffed into the
token when it is created.
JBoss, a division of Red Hat