Skip to content

Commit 214f8be

Browse files
authored
Clarify token request/response example
1 parent 488fcae commit 214f8be

File tree

1 file changed

+11
-9
lines changed

1 file changed

+11
-9
lines changed

IETF-RFC.md

Lines changed: 11 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -1014,7 +1014,8 @@ No user interaction or redirect is involved. [RFC6749]
10141014

10151015
To obtain an access token, the Receiving Server MUST send an HTTP POST
10161016
request to the Sending Server’s tokenEndPoint as discovered in the
1017-
OCM provider metadata.
1017+
OCM provider metadata, following section 4.4.2 of [RFC6749]. Here
1018+
follows an example of such POST request:
10181019

10191020
```
10201021
POST {tokenEndPoint} HTTP/1.1
@@ -1032,22 +1033,22 @@ Signature: sig1=:
10321033
10331034
grant_type=authorization_code&
10341035
client_id=receiver.example.org&
1035-
code=ABCD1234
1036+
code=my_secret_code
10361037
```
10371038

10381039
The request MUST be signed using an HTTP Message Signature
10391040
[RFC9421]. The `client_id` identifies the Receiving Server and MUST be
1040-
set to it’s fully qualified domain name. The `code` parameter carries
1041+
set to its fully qualified domain name. The `code` parameter carries
10411042
the authorization code that was issued by the Sending Server in the
1042-
Share Creation Notification. It is allowed to send the additional
1043-
parameters defined in [RFC6749] for the authorization_code grant type,
1043+
Share Creation Notification. It is allowed to send the additional
1044+
parameters defined in [RFC6749] for the `authorization_code` grant type,
10441045
but they MUST be ignored.
10451046

10461047
## Token Response
10471048

10481049
If the request is valid and the code is accepted, the Sending Server
1049-
MUST respond with HTTP 200 OK and a JSON object containing the issued
1050-
token:
1050+
MUST respond with HTTP 200 OK and a OAuth-compliant JSON object
1051+
containing the issued token:
10511052

10521053
```
10531054
{
@@ -1056,14 +1057,15 @@ token:
10561057
"expires_in": 300
10571058
}
10581059
```
1060+
10591061
The `access_token` is an opaque bearer credential with no internal
10601062
structure visible to the Receiving Server. The token authorizes the
10611063
Receiving Server to access the shared resource using the appropriate
10621064
transport protocol (e.g., WebDAV). The `expires_in` value indicates
10631065
the token lifetime in seconds. No `refresh_token` is issued, instead
10641066
the same request to the tokenEndPoint MUST be repeated before the
1065-
access_token has expired, to recieve a new `access_token` that can then
1066-
be used in the same manner.
1067+
`access_token` has expired, to recieve a new `access_token` that can
1068+
then be used in the same manner.
10671069

10681070
## Error Responses
10691071

0 commit comments

Comments
 (0)