One thing missing from the current access token responses is any indication of where the token can be used.
This seems potentially dangerous as the token might be included when, say, following links or redirects from a protected resource. The solution is probably fairly easy: specify the list of services where the token can be used when the token is issued. 1. A list of domains? 2. A list of “origins” (scheme://host:port)? 3. Allow a wildcard, eg *.example.com? I’ll pick #2. Example: sites=https://api.example.com http://photo.example.com Others have noted the similarities between a bearer token and a cookie. Cookies indicate where they can be used. They also have some other meta-data that might help tokens. For instance, a ‘secure’ field indicating that the token must not be used without https. All this information describing the token deserves its own media type. My suggestion: application/credentials. It could keep the existing syntax, but a little more structure from a syntax such as JSON might be easier. That would also make it easier to include multiple tokens (eg a bearer token, another with a secret, another for a specific service). The refresh_token field would be better thought of as a URI for a token resource. Example: C->S: POST /token/ HTTP/1.1 … C<-S: HTTP/1.1 200 OK Content-type: application/credentials { “location”:”http://as.example.com/token/76875634576387634765374”, “expires_in”:3600, “credentials”:{ { “scheme”:”TOKEN”, “sites”:[“https://api.example.com”, “http://photo.example.com”], “realm”:”General apps”, “id”:”HGF676t7f6f7F67ffr76ff” }, { “scheme”:”BASIC”, “sites”:[“https://blog.example.com”], “realm”:”General apps”, “id”:”dGFDdd464464Ddfd”, “secret”:”tutvT67vV76tvTtvTvTv” } } } Use the “location” field to refresh (or delete) the token. -- James Manger
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
