It's useful to the JavaScript SDK so that it can do REST calls to the server. This
could be used to for example:
* Get login configuration, for example what social providers are enabled for a site. This
can be used to create custom login forms that are well integrated into the site
* Get user profile
* Logout user
It should be an optional value and only needed if the JavaScript SDK is used. It's
also a feature that we wouldn't certainly need for the first milestone
----- Original Message -----
From: "Stian Thorgersen" <stian(a)redhat.com>
To: "Bill Burke" <bburke(a)redhat.com>
Sent: Monday, 22 July, 2013 9:27:58 AM
Subject: Re: [keycloak-dev] CORS
It's useful to the JavaScript SDK so that it can do REST calls to the server.
This could be used to for example:
* Get login configuration, for example what social providers are enabled for
a site. This can be used to create custom login forms that are well
integrated into the site
* Get user profile
* Logout user
It should be an optional value and only needed if the JavaScript SDK is used.
It's also a feature that we wouldn't certainly need for the first milestone
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: keycloak-dev(a)lists.jboss.org
> Sent: Friday, 19 July, 2013 6:40:15 PM
> Subject: [keycloak-dev] CORS
>
>
>
> On 7/19/2013 9:59 AM, Stian Thorgersen wrote:
> >
> > The authorized javascript origin is used to specify what domains are
> > allowed to do CORS request. This is required by the JavaScript SDK so
> > that
> > it can invoke REST endpoints when deployed to a different domain than the
> > IdentityBroker server.
> >
>
> Does Keycloak need CORS? OAuth2 is a redirect protocol.
>
> 1. user visits app
> 2. App redirects to keycloak login screen, sets a session cookie for
> security purposes
> 3. Userlogins into Keycloak
> 4. Keycloak sets a cookie and generates an access code
> 5. Keycloak redirects browser back to app
> 5.1 App checks to make sure it actually made an access code request by
> lookat at the session cookie in step 1.
> 6. App extracts access code from redirect URL
> 7. App makes an under-the-covers invocation to change the short-lived
> access code to a token
> 8. App extracts identity and role-mapping information from token.
> 9. User visits a different site
> 10. Site redirects to keycloak login screen
> 11. Login screen sees that the user is already logged in (via cookie)
> 12. Keycloak generates an access code and redirects to 2nd app
> 13. App extracts access code from redirect URL
> .....
>
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
>
http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>