[keycloak-dev] Keycloak as OAuth 2 compliant authorization server?

[Bill Burke]

On 8/28/2013 9:28 AM, Matt Wringe wrote:
> On 28/08/13 05:45 AM, Marek Posolda wrote:
>> Hi,
>>
>> On 27.8.2013 22:27, Bill Burke wrote:
>>>
>>> On 8/27/2013 4:14 PM, Matt Wringe wrote:
>>>> On Tue 27 Aug 2013 03:50:19 PM EDT, Bill Burke wrote:
>>>>>
>>>>> On 8/27/2013 3:22 PM, Matt Wringe wrote:
>>>>>> On 27/08/13 02:20 PM, Bill Burke wrote:
>>>>>>> Well, you need to remember that OAuth 2 is a framework and not a
>>>>>>> complete protocol.  The actual authentication part with the auth
>>>>>>> server
>>>>>>> is the most "flexible" part of the API.  I'd like to follow it as
>>>>>>> closely as possible though.
>>>>>> Yep, agreed. OAuth does not provide a complete protocol and leaves
>>>>>> a lot
>>>>>> of stuff to the implementors to decide. It also makes a lot of stuff
>>>>>> optional and allows for custom extensions. It does however clearly
>>>>>> defined some areas and provides a defined protocol for them.
>>>>>>
>>>>>> Unfortunately we are not exactly in line with the specification in
>>>>>> all
>>>>>> areas and would need to make some changes to become compliant.
>>>>>>
>>>>>> I am assuming that trying to 'follow it as closely as possible'
>>>>>> means we
>>>>>> do want to be compliant and that issues should be filled where it
>>>>>> does
>>>>>> not follow the defined sections?
>>>>>>
>>>>> What sections do you mean?
>>>> For starters, the authorization grant access is invalid according to
>>>> the
>>>> spec.
>>> I have an idea, but still not exactly sure what you're talking about.
>>> Section 4.4 talks about getting access tokens through a direct grant.
>>> Section 4.3 talks about getting a token by providing both the
>>> username/password and the client's username/password.
>>>
>>> We can't really follow these protocols exactly as we're not going to be
>>> using Basic Auth.
>
> So just for clarification, keycloak is not planning on being oauth
> compliant, we are planning on being something oauth like. Is this
> correct? If so, does it even make sense to mention oauth in the project?
> Its probably just going to confuse people.
>

No, its not going to confuse people and there's no such thing as "OAuth 
Compliant".  OAuth 2.0 is a framework not a full protocol, hence the 
title "The OAuth 2.0 Authorization Framework".

Also, go read the 1st paragraph of section 2.3, and the followup in 
2.3.2.  The auth server is allowed to do anything it wants as far as 
authentication goes.

> Is there any reason why we are not trying to make keycloak compliant
> with oauth? Is this due to trying to create a more locked down
> experience and not exposing some of the more riskier scenarios that
> oauth supports?
>

Read my other email.

"We'll definitely support 4.1 irregardless.  Not sure I want to ever
support 4.2, Implicit, as JSONP has security implications.  4.3 and 4.4
should have a switch on whether to allow them or not."

Please read my other replies too, specifically:

"We can bring back Basic Auth for password only clients if you think we
should.  Its not a big deal.  The original Resteasy OAuth actually does
provide Basic Auth as an option.  In Keycloak I changed it to form
parameters to be consistent as we will offer multi-factor authentication
for users and clients.  Password, TOTP, and/or Client cert.  IMO, it
just seemed more consistent to use the same model for all auth types
rather than offer multiple ways to do the same thing.  We're just
talking about FORM parameters here."

I'll add to this that I also made the FORM parameters consistent across 
all modes of authentication.  Both, OAuth client authentication and User 
authentication.


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