onelifevibe

Glossary

OAuth 2.1

OAuth 2.1 is the consolidated OAuth 2.0 revision requiring PKCE. OneLifeVibe's account connector uses it for MCP access tokens.

Updated November 6, 2026

Standard
draft-ietf-oauth-v2-1

At OneLifeVibe

Related terms

What it means

OAuth 2.1, specified as draft-ietf-oauth-v2-1, is the consolidated revision of OAuth 2.0. It keeps the authorization framework developers already know, makes PKCE mandatory for the authorization code flow, and removes the implicit and password grants. The result is a smaller set of flows to implement and test.

The term describes delegated authorization, not authentication by itself. A client obtains an access token from an authorization server and presents that token to a protected resource. The resource decides what the token allows; the client does not collect or store the user's password.

How it works

With the authorization code flow, the client sends the user to an authorization server. The user signs in there, and the server redirects back with an authorization code. The client exchanges that code for tokens at the token endpoint. PKCE adds a pair of values to that exchange: the client creates a random code verifier, sends a transformed code challenge with the authorization request, and sends the original verifier when redeeming the code. S256 means the challenge is a SHA-256 hash of the verifier. An intercepted code is then useless without the verifier.

Protected resources expect a bearer token, usually in the Authorization header. If the token is missing or not accepted, the resource returns HTTP 401 and includes a WWW-Authenticate header. That header can point to protected resource metadata, which tells the client which authorization server to use and what the resource expects. A client that hits a 401 should read the header, obtain a token through the correct flow, and retry.

How OneLifeVibe uses it

OneLifeVibe's account connector uses OAuth 2.1 authorization code with PKCE (S256). The authorization server, or issuer, is https://accounts.onelifevibe.com/realms/olv. It is a Keycloak identity provider. Clients should run the authorization code flow against that issuer and send the S256 code challenge with the authorization request.

Every request to the MCP server must include Authorization: Bearer <access token>. If the header is absent, the MCP server answers 401 and returns a WWW-Authenticate header that points at the protected resource metadata. Read that metadata for the resource details, then complete the flow and send the resulting access token as a bearer token on the retry.

Common mistakes

The most common error is treating OAuth 2.1 as a brand-new protocol. It is a consolidation: the authorization code flow remains, PKCE is required, and the implicit and password grants are gone. Build for that smaller surface.

Another mistake is omitting PKCE or using a plain verifier. OneLifeVibe specifies S256, so the challenge must be the SHA-256 transformation of the verifier, not the verifier itself. Finally, do not ignore a 401 from the MCP server. The WWW-Authenticate header is part of the protocol response; it tells you where the protected resource metadata lives and gives you the next step.

Questions

What issuer does OneLifeVibe use for OAuth 2.1?

The issuer is https://accounts.onelifevibe.com/realms/olv, a Keycloak identity provider. Use it as the authorization server in the authorization code with PKCE (S256) flow for the account connector.

Why does the OneLifeVibe MCP server return 401?

A request without Authorization: Bearer <access token> gets HTTP 401. The response includes a WWW-Authenticate header pointing at the protected resource metadata. Read that header, complete the flow, and retry with the access token.

See it working. The OneLifeVibe connector and Platform API put these pieces together.

Get a free key Read the docs

Written from the OneLifeVibe tool registry and platform configuration, and checked automatically before publishing. Something wrong? Tell us.