OAuth 2 MAC tokens 01 #29

Open
ib-lundgren opened this Issue May 1, 2012 · 7 comments

Comments

Projects
None yet
5 participants
@ib-lundgren
Collaborator

ib-lundgren commented May 1, 2012

Currently tokens.py match the 00 version of the MAC token spec which is also the one linked from the OAuth 26 draft. A new 01 version of the MAC token spec removes hashing of the body and possibly other things. The OAuth 2 draft is considered stable by now but I am uncertain if this is the case for MAC tokens too.

Update: The MAC token type is currently not maintained and considered incomplete. Might be better to let it stay on v.00 and wait until the mac token spec is picked up and approaching stable.

@lalinsky

This comment has been minimized.

Show comment Hide comment
@lalinsky

lalinsky Nov 10, 2012

Contributor

I'm interested in having a library that works with the 01 MAC tokens. The current code for 00 tokens doesn't really work:

  • there is no standard way to pass the MAC key, etc.
  • it uses non-existent functions (utils.generate_nonce, utils.generate_timestamp)
  • the nonce parameter is constructed incorrectly, it should be age:nonce, but the code currently does nonce:age
  • there is no way to specify the token issue time, so the code can't really generate the age component of the nonce parameter

Do you think it's useful to keep the 00 code and perhaps try to fix it? If I want to add 01 support, should I keep both?

Contributor

lalinsky commented Nov 10, 2012

I'm interested in having a library that works with the 01 MAC tokens. The current code for 00 tokens doesn't really work:

  • there is no standard way to pass the MAC key, etc.
  • it uses non-existent functions (utils.generate_nonce, utils.generate_timestamp)
  • the nonce parameter is constructed incorrectly, it should be age:nonce, but the code currently does nonce:age
  • there is no way to specify the token issue time, so the code can't really generate the age component of the nonce parameter

Do you think it's useful to keep the 00 code and perhaps try to fix it? If I want to add 01 support, should I keep both?

@ib-lundgren

This comment has been minimized.

Show comment Hide comment
@ib-lundgren

ib-lundgren Nov 11, 2012

Collaborator

I noticed you added support for both, let's keep it that way until there is some more progress on the draft and then follow the latest draft. As far as I know none is currently working on the draft as they are lacking clear use cases for when to use MAC tokens. If you happen to have one I'm sure they would be very interested to hear about it =)

Collaborator

ib-lundgren commented Nov 11, 2012

I noticed you added support for both, let's keep it that way until there is some more progress on the draft and then follow the latest draft. As far as I know none is currently working on the draft as they are lacking clear use cases for when to use MAC tokens. If you happen to have one I'm sure they would be very interested to hear about it =)

@ib-lundgren

This comment has been minimized.

Show comment Hide comment
@ib-lundgren

ib-lundgren Mar 27, 2013

Collaborator

Seem to be some progress on MAC tokens http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03, will keep an eye on it.

Collaborator

ib-lundgren commented Mar 27, 2013

Seem to be some progress on MAC tokens http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03, will keep an eye on it.

@mvanderkolff

This comment has been minimized.

Show comment Hide comment
@mvanderkolff

mvanderkolff Nov 13, 2013

Annoyingly enough, there's a random webservice (smsglobal.com) that thought the MAC spec (v1, I think) was a good idea...

Annoyingly enough, there's a random webservice (smsglobal.com) that thought the MAC spec (v1, I think) was a good idea...

@thedrow

This comment has been minimized.

Show comment Hide comment
@thedrow

thedrow Aug 24, 2014

Collaborator

Now in draft 05. The current implementation is 02 (according to the comments).
Should we update it or wait until the spec matures?

Collaborator

thedrow commented Aug 24, 2014

Now in draft 05. The current implementation is 02 (according to the comments).
Should we update it or wait until the spec matures?

@ib-lundgren

This comment has been minimized.

Show comment Hide comment
@ib-lundgren

ib-lundgren Sep 1, 2014

Collaborator

Not followed the changes as of late. However a quick look at the spec and
I'd say it's grown a bit in complexity since last with a few more fields in
the auth header. We could probably update but maybe hold off till there at
least is a full example?

On Sun, Aug 24, 2014 at 3:10 PM, Omer Katz notifications@github.com wrote:

Now in draft 05. The current implementation is 02 (according to the
comments).
Should we update it or wait until the spec matures?


Reply to this email directly or view it on GitHub
idan#29 (comment).

Collaborator

ib-lundgren commented Sep 1, 2014

Not followed the changes as of late. However a quick look at the spec and
I'd say it's grown a bit in complexity since last with a few more fields in
the auth header. We could probably update but maybe hold off till there at
least is a full example?

On Sun, Aug 24, 2014 at 3:10 PM, Omer Katz notifications@github.com wrote:

Now in draft 05. The current implementation is 02 (according to the
comments).
Should we update it or wait until the spec matures?


Reply to this email directly or view it on GitHub
idan#29 (comment).

@foxx

This comment has been minimized.

Show comment Hide comment
@foxx

foxx Jul 1, 2015

Contributor

Looks like this is still in draft 05. There are some examples in there, someone will need to try and implement based on those examples and see if it's complete enough.

Contributor

foxx commented Jul 1, 2015

Looks like this is still in draft 05. There are some examples in there, someone will need to try and implement based on those examples and see if it's complete enough.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment