What is the expected statefulness of an authentication code when the client is explicitly trusted when authenticated? Is the authentication code expected to be per permission owner, or per client?
We have several websites and are setting up Single Sign On between them, so we don't have a concept of prompting the user to authorize the client. They authenticate with the authorization server, then are redirected back to the originating client, and then each authorized client can access various bits of user information (that they are scoped for). The central authorization server is serving tokens and user information for authorized clients (our websites). So technically, my authorization server could authorize a client (one of our websites) once, and the authorized client could reuse the authentication code to get scoped tokens for each authenticated user (until the authentication code expires, or is revoked). I don't know if this is the optimal approach, as it feels like it deviates from the spec. The spec does mention a case where the client can request an authorization code but receive a token instead. In this case, there is no stateful authentication code (because the permission owner isn't authorizing anything), but by passing the client_id and client_secret during the authorization code request handshake, the authorization server would validate the explicitly authorized client and would simply return a token for use by the client for subsequent requests. Each client (each of our websites) would end up getting different tokens for the same user (which could ultimately have different scopes). Does this seem like the better approach than the stateful authentication code? Thanks! -- You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
