aboutsummaryrefslogtreecommitdiffstats
path: root/posts/as_discovery.md
blob: 547455c4941533dfc0d3781e5fdc285fefc48c20 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
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)