Subject: [OAUTH-WG] Using SAML2 Bearer for the authentication

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 19 Feb 2013 13:54:24 +0000

Hi,

Assertions like SAML2 Bearer can be used for authenticating the client.
Why a dedicated Authorization scheme can not be introduced, instead of 
or in addition to "client_assertion" & "client_assertion_type" parameters ?

IMHO, the following

Authorization: SAML "base64url-encoded assertion"

grant_type=authorization_code&code=123456

is more in line with OAuth2 recommending not to prefer including client 
id & secret in the body:

"Including the client credentials in the request-body using the two
parameters is NOT RECOMMENDED and SHOULD be limited to clients unable
to directly utilize the HTTP Basic authentication scheme (or other
password-based HTTP authentication schemes)" - though it talks about a 
password based scheme...

similarly:

Authorization: JWT "encoded jwt assertion"

grant_type=authorization_code&code=123456

Just a thought.

Cheers, Sergey

---

From: Brian Campbell <[email-masked]>
Date: Tue, 19 Feb 2013 07:27:19 -0700

The scope of assertion based client authentication is only in OAuth and
only for the client calling the AS's token endpoint. Defining a general
HTTP auth scheme for assertions would have a much broader scope and be much
more difficult to standardize.

On Tue, Feb 19, 2013 at 6:54 AM, Sergey Beryozkin <[email-masked]>wrote:

> Why a dedicated Authorization scheme can not be introduced, instead of or
> in addition to "client_assertion" & "client_assertion_type" parameters ?
>
> IMHO, the following
>
> grant_type=authorization_code&**code=123456
>
> is more in line with OAuth2 recommending not to prefer including client id
> & secret in the body:
>
> grant_type=authorization_code&**code=123456
>
> Just a thought.
>
> Cheers, Sergey
>
>
> ______________________________**_________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth>
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 20 Feb 2013 11:45:13 +0000

On 19/02/13 14:27, Brian Campbell wrote:
> HTTP auth scheme for assertions would have a much broader scope and be
> much more difficult to standardize.
Understood, thanks.

I'd like to ask another question related to the subject of this thread, 
though the same would likely be relevant for using JWT for authenticating.

When the assertion is used for authenticating the client, a form 
"client_id" parameter is said to be optional.
Next, section 6.1 [1] says that "Subject" of the assertion SHOULD be 
"client_id".

I interpret it like this.

If "Subject" is set to "client_id" then there the actual client_id must 
be available as "client_id" form parameter, which will be posted 
alongside the assertion.

If not then the client_id is an actual Subject value and no "client_id" 
form parameter is expected to be available.

Is it correct ?

Thanks, Sergey

[1] http://tools.ietf.org/html/draft-ietf-oauth-assertions-10#section-6.1

>
>
> On Tue, Feb 19, 2013 at 6:54 AM, Sergey Beryozkin <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     Why a dedicated Authorization scheme can not be introduced, instead
>     of or in addition to "client_assertion" & "client_assertion_type"
>     parameters ?
>
>     IMHO, the following
>
>     grant_type=authorization_code&__code=123456
>
>     is more in line with OAuth2 recommending not to prefer including
>     client id & secret in the body:
>
>     password-based HTTP authentication schemes)" - though it talks about
>     a password based scheme...
>
>     similarly:
>
>     grant_type=authorization_code&__code=123456
>
>     Just a thought.
>
>     Cheers, Sergey
>
>
>     _________________________________________________
>     OAuth mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/oauth
>     <https://www.ietf.org/mailman/listinfo/oauth>
>
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 21 Feb 2013 10:02:10 +0000

> form parameter is expected to be available.
Continuing on this,

http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-15#section-3

says "For client authentication, the Subject MUST be the "client_id" of 
the OAuth client."

This makes me think I may've been wrong with my initial reading of both 
drafts, now I read like this:

"the Subject MUST be the "client_id" of the OAuth client." as per the 
Saml2 bearer draft, which is not the literal "client_id". Next, if 
"client_id" form parameter is available then it must be equal to Subject 
value, as is, or via an AS provided mapping, otherwise it is a 
validation fault.
This is probably in line with the answers to the similar question on the 
use of client_id and JWT grant, though I'm not sure.

I appreciate it is a work in progress, but IMHO some more clarifications 
in the text will help

Cheers, Sergey

---

From: Brian Campbell <[email-masked]>
Date: Thu, 21 Feb 2013 11:30:39 -0700

Yeah Sergey, your second interpretation is more along the lines of what the
draft(s) intended to convey.

The drafts are all due (overdue really) for an update and I'll try and and
some clarifications around this when I get to doing the edits.

Thanks for the feedback.

On Thu, Feb 21, 2013 at 3:02 AM, Sergey Beryozkin <[email-masked]>wrote:

> http://tools.ietf.org/html/**draft-ietf-oauth-saml2-bearer-**15#section-3<http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-15#section-3>
>
> value, as is, or via an AS provided mapping, otherwise it is a validation
> fault.
>> [1] http://tools.ietf.org/html/**draft-ietf-oauth-assertions-**
>> 10#section-6.1<http://tools.ietf.org/html/draft-ietf-oauth-assertions-10#section-6.1>
>>
>>
>>
>>
>>>
>>> grant_type=authorization_code&**__code=123456
>>>
>>> grant_type=authorization_code&**__code=123456
>>>
>>> Just a thought.
>>>
>>> Cheers, Sergey
>>>
>>>
>>> ______________________________**___________________
>>> OAuth mailing list
>>> https://www.ietf.org/mailman/_**_listinfo/oauth<https://www.ietf.org/mailman/__listinfo/oauth>
>>> <https://www.ietf.org/mailman/**listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth>
>>> >
>>>
>>>
>>>