OAuth 2.0 Integration Overview

36Blocks can act as an OAuth 2.0 authorization server for your block, letting third-party applications request delegated, scoped access to your users' accounts. It's the same shape as "Connect to GitHub" or "Sign in with Google," but for your own product.

#

The four roles

OAuth role

Who this is

Resource Owner

Your end user (the person who has an account on your block).

Authorization Server

36Blocks. We authenticate your user, run the consent screen, and issue the access token.

Resource Server

Your own platform/API. A third-party app uses the access token we issue as its credential when calling your APIs.

Client

The third-party application requesting access to your user's data.

You control which third-party apps are allowed to request access (by registering each one as an OAuth Config), and which pieces of data they can ask for (via scopes).

#

Key concepts

OAuth Config: one registered third-party integration for your block. Has a client_id (public identifier) and, for confidential clients, a client_secret. You create and manage these from your block's dashboard.

Client type: public or confidential, chosen once when you create the config and not changeable afterward.

  • Confidential clients (a server-side backend that can keep a secret) get a client_secret and authenticate with it.

  • Public clients (a mobile app or single-page app that can't safely hold a secret) have no secret and must use PKCE instead.

PKCE: a proof-of-possession mechanism that protects the authorization code from being intercepted and used by someone other than the app that started the flow. Always required for public clients, optional (but available) for confidential ones. If you're not already familiar with PKCE, RFC 7636 is the reference; this guide shows exactly what to send where.

Scopes: what a connected app is allowed to access. Two are built in:

Scope

Grants

profile

Name, mobile number, profile picture URL

email

Email address

You can also define your own custom scopes (e.g. tickets:read) for anything specific to your own product. 36Blocks treats these as opaque strings; it's up to your own backend to actually enforce what a custom scope allows, by checking the token's granted scopes (via the Me endpoint) before serving the data it's meant to gate.

If a connecting app doesn't send any scopes at all, that's fine. The flow still completes normally, it just means the app gets no profile/email data and no custom scopes, only a stable user identifier.

#

The flow, end to end

  1. You set up an OAuth Config and (optionally) custom scopes from your block's dashboard. See Dashboard setup.

  2. You host a consent screen, a page on your own domain where you embed 36Blocks' widget. See Consent screen. The third-party app redirects your user's browser there with its OAuth request appended to the URL.

  3. Your user logs in (or signs up) and approves or denies the request, using the exact same login UI your users already see today.

  4. The widget redirects the browser back to the third-party app's own redirect_uri, with a one-time authorization code attached (or an error if denied).

  5. The third-party app's backend exchanges that code for an access token and refresh token. See Token endpoint.

  6. The third-party app calls the Me endpoint to get the user's identity and confirm exactly which scopes were granted. See Me endpoint.

  7. The third-party app refreshes the access token as needed, using the same token endpoint. Also covered in Token endpoint.

  8. Either your user or you can revoke access at any time. See Revoking access.

Steps 1-2 are things you do once per integration. Steps 3-8 happen automatically through the widget and the APIs documented in this guide; the third-party app's own developer is the one who implements steps 4-7 against the API reference pages.

Built with DocStar