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

[Bill Burke]

On 8/28/2013 5: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.  IMO, the spec is really unclear at what is required
>> and what is optional for authentication in section 3.2.1.
> Actually the section 3.2.1 points to section 2.3 and in section 2.3.1 is
> mentioned that "The authorization server MUST support the HTTP Basic
> authentication scheme for authenticating clients that were issued a
> client password. "
>

The 1st paragraph of 2.3:  "The authorization
    server MAY accept any form of client authentication meeting its
    security requirements."

2.3.2 also says that the auth server can basically do whatever it wants 
based on its requirements.


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.


> In specs is also mentioned alternative that authorization server may
> support credentials in request body in parameters "client_id",
> "client_secret", which is currently the case used in Keycloak. But
> instead of "client_secret" Keycloak is using parameter named "password"
> in Access Token Request (request for exchange code to access token). I
> think that this is due to simplification as same parameter "password"
> could be used by AuthenticationManager to authenticate both normal users
> and client applications, not sure if this could be treated as breaking
> the specs or not. I agree that spec is quite unclear in many points...
>

It then goes on in 2.3.2 stating that the auth server can do whatever it 
wants....



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