[keycloak-dev] SaaS login

[Bill Burke]

Feel free to keep arguing, but I don't agree yet.  The admin UI is not a 
remote application, it is served up by the same web app as where the 
REST services driving it are deployed.  This is a very important 
distinction.  Because of this, the protocol can be much more efficient.

OAuth requests:

1. GET app URL
2. redirect from app to token service, display login screen
3. submit login
4. redirect back to app
5. Make a separate non-browser HTTP request to obtain access code

Also, in steps 1-5 a client is involved.  This client is requesting 
access on behalf of the user.  So, step 2 requires knowledge of the 
client id.  It actually checks to see if the client is even allowed to 
display a login screen.  Step 3 needs to check if the client requires 
the OAuth Grant page, it also registers an access code which is 
transmitted to the client in step 4  The client will turn this access 
code into a token in step 5.

Also, step 2 involves setting a "state" cookie who's value is also 
embedded in the redirect url in step 2.  The state value is 
retransmitted in the redirect URL in step 4.  And step 5 validates the 
"state" cookie

Saas login

1. Get login screen
2. submit login, response is the admin UI

This algorithm doesn't involve a client at all.  Also, if you look at 
the admin UI it has no knowledge of a token.  It just makes REST 
requests which are authenticated by a session cookie.  Remote 
applications actually work in the same exact way after they obtain their 
token.  They set a session cookie and store identity in the server's 
HttpSession.  For keycloak, we store the identity in the session cookie 
so we can have stateless backend.






On 8/6/2013 4:23 AM, Stian Thorgersen wrote:
> IMO that's a mistake, there's a lot of duplicated code, and you'll also want to support social login etc. (so more duplicated code) or SaaS when/if it comes to a free "trial" online.
>
> As admin is a JavaScript application it is clearly a remote application and could login the same way as any other remote application does, i.e. through TokenService. The only difference in the two scenarios is that for the admin rest endpoints it would be a small optimization to allow validating the token without a remote call, which would be beneficial for folks that wants to use keycloak for smaller internal deployments (e.g. a single app server running a rest/js style app).
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Monday, 5 August, 2013 7:26:06 PM
>> Subject: Re: [keycloak-dev] SaaS login
>>
>> TokenService is really for a remote service that is using keycloak to
>> authenticate.  Its all the same server so no need for the extra
>> redirects and thus no need for the Token Service endpoints.
>>
>> On 8/5/2013 11:14 AM, Stian Thorgersen wrote:
>>> I was wondering why there are separate login/logout endpoints in
>>> SaasService? Should this not use the standard mechanism to do this (i.e.
>>> TokenService)?
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com