Thanks Sergey. I will hold my horse to go with the MAC token type till I
can see the true benefits then. ;-)


On Tue, Dec 10, 2013 at 12:27 AM, Sergey Beryozkin <[email protected]>wrote:

> Hi
>
> On 08/12/13 10:08, Jason Wang wrote:
>
>> Hi all,
>>
>> I am looking at different token types in Oauth2. I am having trouble
>> understanding the benefits of using MAC over the simple Bearer token.
>>
>> It looks to me using MAC token can prevent replay attacks as it uses a
>> nonce.
>>
>
> The idea is also to support a holder-of-key concept.
> Note CXF supports the earlier, much simpler version of the MAC spec,
> authored by E. Hammer-Lahav. The current OAuth2 Mac spec is being worked
> upon, I think it is much more sophisticated, linked to JWT, so haven't
> tried to implement it yet. I'll have no problems supporting original
> version as a custom MAC token type, OAuth2 is OK with custom types.
>
>
>  But if SSL is used, those attacks are no longer possible (assuming a
>> proper SSL implementation).
>>
>> It mentions in the spec a two way TSL is recommended.
>>
>
> Do you refer to an actual spec text or to the text on CXF wiki ? I added
> the latter, it only applies to the process of the client requesting the MAC
> token, for the actual MAC key to be absolutely safely transmitted back to
> the client. Of course, a one-way TLS can be secure enough too if no hacker
> risks exist.
>
>
>
>  Doesn't that mean
>> this mac token is not ideal for mobile/native apps where its impossible to
>> safe guard a client certificate?
>>
> I guess you are right.
> Note CXF supports
> http://tools.ietf.org/html/draft-sakimura-oauth-tcse-01
>
> but
>
> http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02
>
> has already superseded it - I'll try to implement it for 3.0.0 m2, not
> sure it will help in you scenario though
> Thanks
> Sergey
>
>>
>> Many thanks?
>>
>> Jason
>>
>>
>

Reply via email to