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

[Marek Posolda]

On 28.8.2013 15:41, Bill Burke wrote:
>
>
> 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.
I agree that specification is quite "free" at this point.

However I don't think that it's a big deal to use parameter named 
"client_secret" instead of "password" for password-based authentication 
of client applications (ie. keycloak users with role RESOURCE_ROLE or 
IDENTITY_REQUESTER_ROLE). AFAIK OAuth2 providers like Facebook or Google 
are using "client_secret" for this. Of course, the possible drawback of 
different name is consistency... I am really not sure which possibility 
is better, just wanted to mention possible specs incompatibilities when 
we are in this discussion:-)

I am leaving the decision to you.

Marek
>
>
>> 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....
>
>
>