A nomenclature distinction that might help this conversation: *authentication* verifies *identity* (via, e.g., userid/passwd, public key negotiation, etc.) and may issue a token (e.g., a cookie, Kerberos TGT, etc.).
*authorization* determines what an authenticated identity (and its associated roles, if any) have access to in an application context (realm?). These are standard terms, and the activities they refer to should be orthogonal. Neither the OP nor Glyph use the term "authorization" in either of their messages, but that concept is clearly involved and is almost always useful for clarification. Looking at the OAuth 2.0 protocol specification, it seems quite similar in concept to Kerberos (and other SSO protocols), in which the user acquires a Ticket-Granting Ticket (TGT) upon authentication to a Kerberos domain controller, and then the TGT is used when interacting with applications in the Kerberos domain. Each app is registered with the Kerberos domain controller and can interact with it securely to verify the validity (also expiration time, etc.) of a TGT that has been offered to it. Once that interaction is complete, the app knows the identity associated with the TGT has been authenticated, and it can proceed with authorization, which of course depends on each application's context, and is completely separate from authentication. It might be useful to describe cred's structure in these terms, since both authentication and authorization are involved. (Might be useful to me, at least ... :) Steve _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
