Thank you for your advice. The Oauth security considerations are not finished yet. They will handle the issues you raised, too.
Regards, Torsten. Am 30.09.2010 um 01:33 schrieb PRATEEK MISHRA <prateek.mis...@oracle.com>: > I read through v10 from the perspective of an implementor, and it seemed to > me that properties of generated authorization code and its treatment by > various entities need to be called out explicitly as a counter-measure > against various simple attacks. > > I would also comment that the exchanges between the end-user, client and > authorization endpoints, beginning with the issuance of an authorization code > (in SAML 2.0 called a browser artifact) and terminating with the client > obtaining an access token (in SAML 2.0 the RP obtaining a SAML assertion) > essentially follow the SAML web browser artifact profile and are therefore > open to all of the attacks that the SSTC considered for this protocol. > > 1) For example, given the current description it seems that perfectly > reasonable for an end-user authorization endpoint to generate a sequence of > increasing integers as an authorization code or always return a constant > value for a request with a given (client_id, redirection_uri) pair of inputs. > So this leads to the possibility of an adversary using some simple techniques > to guess valid authorization codes and obtain an access token. > > 2) There is a need to articulate some of the minimum properties that an > authorization code should possess. I understand that there is an attempt here > to give maximum choice to implementors. > > For example, the SAML 2.0 artifact format description includes the following > language - > > [quote] > The MessageHandle value is constructed from a cryptographically strong random > or > pseudorandom number sequence [RFC1750] generated by the issuer. The sequence > consists of > values of at least 16 bytes in size. > [\quote] > > > 3) I am also puzzled by the discrepancy between the language used to describe > the generation and use of an authorization code - > > [quote - generation - p.18] > The authorization code > SHOULD expire shortly after it is issued. The authorization > server MUST invalidate the authorization code after a single > usage. The authorization code is bound to the client > identifier and redirection URI. > [\quote] > > VS > > > [quote - use - p.23] > The authorization server MUST: > o Validate the client credentials (if present) and ensure they match > the authorization code. > o Verify that the authorization code and redirection URI are all > valid and match its stored association. > [\quote] > > > I dont understand how the authorization code is related to the client > credentials, or what is meant by "valid" or the reference > to "stored association". Is there an assumption that authorization server has > a stateful table of (authorization code, client id, redirection uri) values? > Shouldnt this test be limited to checking whether the authorization code is > being used with the correct client identifier and redirection URI? > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
