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

[Matt Wringe]

On 27/08/13 04:27 PM, 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.
>
>> Not sure which auth grants we want to support in oauth exactly, if
>> any since technically we could have just a custom one instead. But even
>> with custom auth grants, we still have to conform to the protocol.
>>
>
> Again, you aren't specifying where we're not compliant.

http://tools.ietf.org/html/rfc6749#section-3.1.1
We don't send the response_type to the authorization server, its the 
only required parameter and we have to throw an error in this case 
according to the specification.

Should more issues be brought up in this email or would separate jiras 
be better?

>
>> It gets tricky depending on how customized we want to go with things
>> though. If we decide not to support any of the default auth grants or
>> the other optional features, then most of the specification no longer
>> applies to us.
>>
>
> 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.

Is what we currently have is suppose to be 4.1?