Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[proposal] Add auth as a capability with support for OAuth 2.0 and secrets. #101

Closed
wants to merge 8 commits into from
Closed

[proposal] Add auth as a capability with support for OAuth 2.0 and secrets. #101

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
c14139b
Add section for auth proposal
k6l3 Dec 6, 2024
9b9340d
Apply suggestions from code review
k6l3 Dec 8, 2024
a5ff8c2
Update spec
k6l3 Dec 9, 2024
ee1676b
Apply suggestions from code review
k6l3 Dec 9, 2024
b19ccfe
Move into _meta
k6l3 Dec 9, 2024
1a665e3
Move things into draft, drop credential auth
k6l3 Dec 20, 2024
12f3ab9
Add auth field to schema
k6l3 Dec 20, 2024
c9f37bb
Update schema json
k6l3 Dec 20, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 9 additions & 7 deletions docs/specification/auth/credential.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -76,7 +76,7 @@ Clients can list required credentials with an `auth/credentials/list` capability

### Providing Credentials

Clients **MUST** provide credentials through headers during initialization:
During initialization, if the client and server both support the `credentials` capability, the client **SHOULD** provide credentials as parameters during initialization:

```json
{
Expand All @@ -86,13 +86,15 @@ Clients **MUST** provide credentials through headers during initialization:
"params": {
"capabilities": {
"auth": {
"credential": true
"credentials": true
}
},
"auth": {
"credentials": {
"API-KEY": "api_key",
"MISC-PASSWORD": "password"
"_meta": {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I meant using the _meta field outside of initialization only. 😅

Rationale:

  1. It's an essential part of initialization semantics
  2. It's an out of band addition to every other request type

I think just params.auth is fine during init.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, I think I would prefer consistency here. Providing it as part of _meta in initialization would be the same as making a request with headers. If the server finds valid credentials, it can present a larger suite of capabilities?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The thing is that the initialize request is basically all headers (by analogy).

"auth": {
"credentials": {
"API-KEY": "api_key",
"MISC-PASSWORD": "password"
}
}
}
}
Expand All @@ -104,7 +106,7 @@ Clients **MUST** provide credentials through headers during initialization:
When credentials are missing or invalid, servers **MUST** respond with at least an error code.

**Response:**
```json
```typescript
{
"jsonrpc": "2.0",
"id": 1,
Expand Down
18 changes: 10 additions & 8 deletions docs/specification/auth/oauth2.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -37,7 +37,7 @@ sequenceDiagram
Client->>AuthServer: Refresh Token Request (auth/oauth2/token)
AuthServer->>Client: New Access Token

Note right of client: Revoking tokens:
Note right of Client: Revoking tokens:
Client->>AuthServer: Revoke Token Request (auth/oauth2/revoke)
```
Note that the authorization server may be the same server as the resource server or a separate entity. A single authorization server may issue access tokens accepted by multiple resource servers.
Expand Down Expand Up @@ -82,7 +82,7 @@ During initialization, if the client and server both support the `oauth2` capabi
To obtain an access token, clients **MUST** send an `auth/oauth2/authorize` request.

**Request:**
```json
```typescript
{
"jsonrpc": "2.0",
"id": 1,
Expand Down Expand Up @@ -129,7 +129,7 @@ After receiving the authorization code, the client **SHOULD** exchange it for to

The server responds with tokens:

```json
```typescript
{
"jsonrpc": "2.0",
"id": 2,
Expand Down Expand Up @@ -158,9 +158,11 @@ Once a client has obtained an access token, it **SHOULD** include it in all requ
"id": 1,
"method": "...",
"params": {
"auth": {
"oauth2": {
"access_token": "..."
"_meta": {
"auth": {
"oauth2": {
"access_token": "..."
}
}
}
}
Expand All @@ -173,7 +175,7 @@ If the client has a refresh token, the client **SHOULD** automatically request a

**Request:**

```json
```typescript
{
"jsonrpc": "2.0",
"id": 1,
Expand Down Expand Up @@ -207,7 +209,7 @@ The response will be identical to obtaining an access token for the first time.
If a request failed client authentication or is invalid the server should respond with an error response as described in [Section 5.2 of RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749#section-5.2).

**Response:**
```json
```typescript
{
"jsonrpc": "2.0",
"id": 1,
Expand Down
Loading