OAuth Client Architectures

​

Overview

• Where do the tokens live? A Mighty API access token is a bearer credential that acts as the user. Anyone holding it can do everything that user approved.
• Who can exchange an authorization code for tokens? That party acts as your application.

​

Pick your architecture

​

Backend web apps

​

Native mobile and desktop apps

Native app            System browser         Mighty
    |                       |                   |
    |  open authorize URL   |                   |
    |  (state + S256        |                   |
    |   challenge)          |                   |
    |---------------------->|  /oauth/authorize |
    |                       |------------------>|
    |                       |  sign in, consent |
    |                       |<------------------|
    |  redirect to the app  |                   |
    |  claimed https:// URI |                   |
    |<----------------------|                   |
    |                                           |
    |  POST /oauth/token                        |
    |  code + code_verifier + client_id         |
    |------------------------------------------>|
    |                                           |
    |  access_token + refresh_token             |
    |<------------------------------------------|

​

Single-page and embedded apps

• Redirect to a page on your own origin, registered exactly.
• Generate state and the code_verifier per authorization request. state is required on every request to /oauth/authorize.
• Hold the access token in JavaScript memory only. Do not put tokens in localStorage, sessionStorage, or a cookie your scripts can read. A cross-site scripting bug would let an attacker steal the token.
• Expect the user to re-authorize when they reload the tab. That is the trade-off for not having a backend.

​

Apps embedded in a Mighty Network

• /oauth/authorize cannot be framed. Framing is same-origin only, so authorize in a popup or with a top-level redirect. For popups, your callback page can use window.opener to return the result to the embedded page.
• Turn on the sign-in overlay. In the embed dialog, check This embed uses a Mighty OAuth application. Signed-out visitors then see a “Sign in to view this content” overlay before the iframe becomes interactive. See Can I use external embeds?.
• Offer an explicit disconnect. Signing out of Mighty does not sign the member out of your embedded app. Give members a visible disconnect action that calls /oauth/revoke and clears your own session, and tell them to use it on shared devices.
• state still applies. Popups and embeds don’t exempt you from generating and verifying it.

​

Anti-pattern: the token proxy

1. The app opens /oauth/authorize in an embedded WebView.
2. The redirect URI points at the app’s own backend, whose callback page posts the code and state into the WebView through a JavaScript bridge.
3. The app posts that code plus its own code_verifier to a backend endpoint such as /api/auth/token.
4. The backend adds the server-held Client Secret, exchanges the code with Mighty, and returns the user’s access and refresh tokens to the app.

Malicious app         Mighty           Your backend
     |                   |                   |
     |  WebView sign-in, |                   |
     |  attacker's state |                   |
     |  and verifier     |                   |
     |------------------>|                   |
     |  victim signs in  |                   |
     |  code via WebView |                   |
     |  bridge           |                   |
     |<------------------|                   |
     |                                       |
     |  POST /api/auth/token                 |
     |  code + attacker's code_verifier      |
     |-------------------------------------->|
     |                   | + client_secret   |
     |                   |<------------------|
     |                   |  tokens           |
     |                   |------------------>|
     |  victim's access + refresh tokens     |
     |<--------------------------------------|

• PKCE doesn’t help. PKCE proves that whoever redeems the code also started the authorization request. Because the attacker started the request with their own verifier, the proof succeeds for them.
• state doesn’t help. state is a CSRF defense that binds a callback to a session. The attacker generated the state and validates it themselves.
• The Client Secret doesn’t help. Your backend applies the secret on behalf of every caller. Any caller who can trigger the secret can use it as a public credential.
• The WebView is the other half of the problem. Rendering Mighty’s login page inside your app means your app can read the credentials, the session, and the code. Even with a fixed token endpoint, a WebView sign-in is a phishing surface.

​

Correct fixes

​

Token handling

• Read expires_in from the token response rather than assuming a lifetime, and treat access and refresh tokens as high-value credentials for as long as they are valid. Refresh tokens expire and are invalidated by the events listed under Refreshing tokens.
• Refresh tokens rotate. Every grant_type=refresh_token call returns a new access token and a new refresh token, and revokes the one you presented. Persist the new refresh token atomically before you use the new access token.
• invalid_grant on refresh means re-authorize. An already-used or revoked refresh token fails with invalid_grant. Do not retry. Send the user through /oauth/authorize again. Serialize refresh calls so concurrent requests do not invalidate each other’s tokens.
• Revoke on sign-out. Call /oauth/revoke with either token of the pair. See Revoking tokens for the details.

curl https://my-community.mn.co/oauth/revoke \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "token=ACCESS_OR_REFRESH_TOKEN" \
  -d "client_id=YOUR_CLIENT_ID"

​

Where to keep tokens

​

Common questions

​

Review checklist

• The client type matches where the code runs. Use Confidential only where a server keeps the secret and Public everywhere else.
• No Client Secret is present in any mobile binary, desktop build, browser bundle, or repository.
• No endpoint anywhere accepts an authorization code or a code_verifier from a client and exchanges it. The party that generated the verifier is the party that redeems the code.
• Sign-in happens in the system browser (ASWebAuthenticationSession, Custom Tabs) or a top-level page, never an embedded WebView. No authorization code crosses a WebView bridge.
• PKCE with S256 is used on every flow, including confidential ones.
• state is a fresh, cryptographically random, single-use value per request. It is bound to the session and verified on the callback, and iss is also checked to confirm it matches the Network’s issuer.
• Redirect URIs are registered exactly and use claimed HTTPS, a custom scheme, or loopback. They contain no wildcards or open redirectors and do not point to third-party pages.
• Tokens are stored in the platform credential store, server-side encrypted storage, or memory. They are never stored in localStorage or written to logs.
• Token lifetime comes from expires_in. No lifetime is hardcoded.
• Rotated refresh tokens are persisted atomically, refresh calls are serialized, and invalid_grant triggers re-authorization instead of a retry loop.
• Sign-out calls /oauth/revoke and clears local credentials. Embedded apps also expose an explicit disconnect.
• Requested scopes are the narrowest set the feature needs, and the granted scope in the token response is checked rather than assumed.

​

Next steps