diff options
author | François Kooman <fkooman@tuxed.net> | 2016-06-01 08:54:07 +0200 |
---|---|---|
committer | François Kooman <fkooman@tuxed.net> | 2016-06-01 08:54:07 +0200 |
commit | 13feb3f7680723e9ab9c3a889eeeb5f25cc97490 (patch) | |
tree | 2320ba9982640181fd640fbc0e713ddde84342dd /posts/as_discovery.md | |
download | www.tuxed.net-13feb3f7680723e9ab9c3a889eeeb5f25cc97490.zip www.tuxed.net-13feb3f7680723e9ab9c3a889eeeb5f25cc97490.tar.gz www.tuxed.net-13feb3f7680723e9ab9c3a889eeeb5f25cc97490.tar.xz |
initial commit
Diffstat (limited to 'posts/as_discovery.md')
-rw-r--r-- | posts/as_discovery.md | 74 |
1 files changed, 74 insertions, 0 deletions
diff --git a/posts/as_discovery.md b/posts/as_discovery.md new file mode 100644 index 0000000..547455c --- /dev/null +++ b/posts/as_discovery.md @@ -0,0 +1,74 @@ +--- +title: OAuth 2.0 Authorization Server Discovery +published: 2015-07-31 +--- + +### Introduction + +Currently an OAuth client is supposed to know the Authorization Server (AS) +that is used by a particular Resource Server (RS). This blog post proposes a +discovery mechanism where the client only needs to know the location of the RS. + +The RS chooses the AS it will use. There is no point for the client to know +what the AS is beforehand. It can also change at any point at the +RS's discretion. As far as I know there is no standardized way of doing this. + +### Proposal + +Currently, the `WWW-Authenticate` header is sent back by the RS +if no `Authorization` header is provided by the client or if it uses +an invalid or expired token. If the client sends an "unauthenticated" request, +i.e. without the `Authorization` header, like shown below: + +``` +POST /endpoint HTTP/1.1 +Host: rs.example.org +Content-Type: application/x-www-form-urlencoded + +foo=bar +``` + +In most cases this will not succeed, although in some it might if out-of-band +authorization was already establish, e.g. using Kerberos in enterprise +networks. However, in most scenarios this request will not be allowed. +Currently the response would be like this: + +``` +HTTP/1.1 401 Unauthorized +WWW-Authenticate: Bearer + realm="Phubble" +``` + +Now, the OAuth Bearer specification provides for specifying the OAuth scope +required for performing a certain action, e.g. the scope +`https://micropub.net/scope#create` is required to be able to +perform the operation. This field is then included in the +`WWW-Authenticate` header to tell the client which scope to +request: + +``` +HTTP/1.1 401 Unauthorized +WWW-Authenticate: Bearer + realm="Phubble", + scope="https://micropub.net/scope#create" +``` + +Now, for discovery of the AS I propose two new key-value pairs: +`authorization_endpoint` and `token_endpoint`. This will +allow the client to select the correct AS: + +``` +HTTP/1.1 401 Unauthorized +WWW-Authenticate: Bearer + realm="Phubble", + scope="https://micropub.net/scope#create", + authorization_endpoint="https://as.example.org/authorize", + token_endpoint="https://as.example.org/token" +``` + +This proposal thus solves two issues: the discovery of the AS and the discovery +of the required scope for a particular action on the RS's endpoint. + +### References + +- [RFC 6750 "The OAuth 2.0 Authorization Framework: Bearer Token Usage](https://tools.ietf.org/html/rfc6750) |