Skip to content

Commit 5432b8b

Browse files
glpatcernmickenordin
authored andcommitted
Clarify token request/response example
1 parent c0cd2b0 commit 5432b8b

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
@@ -1022,7 +1022,8 @@ No user interaction or redirect is involved. [RFC6749]
10221022

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

10271028
```
10281029
POST {tokenEndPoint} HTTP/1.1
@@ -1040,22 +1041,22 @@ Signature: sig1=:
10401041
10411042
grant_type=authorization_code&
10421043
client_id=receiver.example.org&
1043-
code=ABCD1234
1044+
code=my_secret_code
10441045
```
10451046

10461047
The request MUST be signed using an HTTP Message Signature
10471048
[RFC9421]. The `client_id` identifies the Receiving Server and MUST be
1048-
set to it’s fully qualified domain name. The `code` parameter carries
1049+
set to its fully qualified domain name. The `code` parameter carries
10491050
the authorization code that was issued by the Sending Server in the
1050-
Share Creation Notification. It is allowed to send the additional
1051-
parameters defined in [RFC6749] for the authorization_code grant type,
1051+
Share Creation Notification. It is allowed to send the additional
1052+
parameters defined in [RFC6749] for the `authorization_code` grant type,
10521053
but they MUST be ignored.
10531054

10541055
## Token Response
10551056

10561057
If the request is valid and the code is accepted, the Sending Server
1057-
MUST respond with HTTP 200 OK and a JSON object containing the issued
1058-
token:
1058+
MUST respond with HTTP 200 OK and a OAuth-compliant JSON object
1059+
containing the issued token:
10591060

10601061
```
10611062
{
@@ -1064,14 +1065,15 @@ token:
10641065
"expires_in": 300
10651066
}
10661067
```
1068+
10671069
The `access_token` is an opaque bearer credential with no internal
10681070
structure visible to the Receiving Server. The token authorizes the
10691071
Receiving Server to access the shared resource using the appropriate
10701072
transport protocol (e.g., WebDAV). The `expires_in` value indicates
10711073
the token lifetime in seconds. No `refresh_token` is issued, instead
10721074
the same request to the tokenEndPoint MUST be repeated before the
1073-
access_token has expired, to recieve a new `access_token` that can then
1074-
be used in the same manner.
1075+
`access_token` has expired, to recieve a new `access_token` that can
1076+
then be used in the same manner.
10751077

10761078
## Error Responses
10771079

0 commit comments

Comments
 (0)