Memo Bank Authentication

generated: '2026-08-17'
method: searched
source:
- https://docs.api.memo.bank/authentication
- https://docs.api.memo.bank/topic/topic-getting-started
- https://docs-marketplace.api.memo.bank/authentication
- https://docs-marketplace.api.memo.bank/topic/topic-authorization-flow
- openapi/memo-bank-nextgenpsd2-api-openapi.yml
- openapi/memo-bank-marketplace-api-openapi.yml
- openapi/memo-bank-premium-bank-api-openapi.yml
docs: https://docs.api.memo.bank/authentication
note: >-
  Upgraded from the mechanical derive, which could only see the one oauth2 scheme in the NextGenPSD2 spec.
  The derive was blind to the primary scheme because of a real defect in Memo Bank's contract: all 43
  operations in the Premium Bank OpenAPI declare `security: [{JWT: []}]`, but components.securitySchemes is
  ABSENT from the document, so the JWT scheme is referenced and never defined. The same dangling reference
  appears in the Marketplace spec. Anything reading only the specs concludes there is no authentication
  scheme; the real scheme is documented in prose and is recorded below from that documentation.
summary:
  types:
  - http
  - oauth2
  - mutualTLS
  api_key_in: []
  oauth2_flows:
  - authorizationCode
  primary: >-
    Per-request RS256-signed JWT/JWS bearer token bound to the method, path and body digest - not a static
    API key or a long-lived bearer token.
  spec_defect: >-
    securitySchemes is missing from both the Premium Bank and Marketplace OpenAPI documents while every
    operation references a `JWT` scheme name. This is the single highest-value contract repair available:
    generated clients and API tooling see an undefined security requirement.
schemes:
- name: JWT
  label: Premium Bank API request signing
  type: http
  scheme: bearer
  bearerFormat: JWT
  header: 'Authorization: Bearer <jwt>'
  algorithm: RS256
  declared_in_spec: true
  defined_in_spec: false
  defined_in_spec_note: >-
    Referenced by all 43 operations as `JWT` but absent from components.securitySchemes.
  sources:
  - https://docs.api.memo.bank/authentication
  - openapi/memo-bank-premium-bank-api-openapi.yml
  standards:
  - RFC 7519 (JWT)
  - RFC 7515 (JWS)
  jwt_header:
    alg: Must be RS256 - RSA-SHA256 signature required.
    typ: Must be JWT.
    x5t#S256: SHA-256 thumbprint of the certificate, obtained from the Memo Bank web interface.
  jwt_payload:
    sub: The request method, a space, then the full path including query parameters.
    aud: The domain being called, e.g. api.memo.bank.
    iat: Token creation timestamp. Only 5 seconds of clock skew is tolerated.
    jti: Unique UUID, different for every request.
    sec: Secret code obtained during setup. Custom claim, not part of the JWT spec.
    dig#S256: >-
      base64url(sha256(body)). Required only when the request has a body; omitted for GET. Custom claim, not
      part of the JWT spec.
  signing_key: RSA private key generated by the customer during setup.
  replay_resistance: >-
    Strong. Because sub pins the method and exact path with query string, aud pins the host, jti is unique
    per request, iat is valid for a 5-second window, and dig#S256 pins the body, a captured token cannot be
    reused for a different request or replayed later. In effect this is HTTP message signing expressed as a
    JWT, and it is a materially stronger posture than the bearer API keys most payment APIs ship.
  operational_cost: >-
    The flip side is that there is no first-party SDK (see packages/memo-bank-packages.yml), so every
    customer implements this signing logic themselves. Each constraint - path exactness including query
    order, the 5-second clock window, the conditional body digest - is an independent silent-failure mode
    that surfaces only as a 401.
- name: OAuth2
  label: Marketplace and MCP connector delegated access
  type: oauth2
  flows:
  - flow: authorizationCode
    authorizationUrl: https://client.memo.bank/authorize
    tokenUrl: https://api.memo.bank/oauth2/token
    refreshUrl: https://api.memo.bank/oauth2/token
    grant_types:
    - authorization_code
    - refresh_token
    request_params:
    - client_id
    - redirect_uri
    - scope
    - state
    pkce: not documented
  token_endpoint_operation: openapi/memo-bank-marketplace-api-openapi.yml#createToken
  token_endpoint_auth: >-
    client_id + client_secret in the JSON request body, AND a Memo Bank JWT - the token endpoint itself
    carries security: [{JWT: []}], so an application must sign the token request too.
  token_response_fields:
  - access_token
  - token_type
  - expires_in
  - refresh_token
  - scope
  - connection_id
  token_lifetimes:
    access_token: 2 hours
    refresh_token: 14 days, single use
    authorization_code: 5 minutes, single use
  refresh_rotation: >-
    Refresh tokens are single-use, so each refresh issues a new refresh token - correct rotating-refresh
    behaviour, which limits the value of a stolen token.
  layered_with_jwt: >-
    Marketplace requests carry BOTH credentials at once: the OAuth 2.0 access token in Authorization, and
    the application's JWT in X-Memo-Signature. The JWT payload additionally includes an oat#S256 claim
    holding base64url(sha256(access_token)), which cryptographically binds the application's signature to
    that specific access token. This is proof-of-possession style token binding and is notably stronger than
    a plain bearer token.
  consent_model: >-
    The user picks which workspace(s) the application may act on during authorization, and access is limited
    to both the granted scopes and the specific accounts authorized. Out-of-scope access returns an error.
  connection_model: >-
    One connection per user/workspace pair. connection_id is returned with the token and sent on webhook
    deliveries via X-Memo-Connection-Id. A user-deactivated connection causes requests to fail with
    inactive_connection.
  sources:
  - https://docs-marketplace.api.memo.bank/topic/topic-authorization-flow
  - https://docs-marketplace.api.memo.bank/authentication
  - openapi/memo-bank-marketplace-api-openapi.yml
  scopes_detail: scopes/memo-bank-scopes.yml
- name: OAuth2
  label: NextGenPSD2 XS2A delegated access
  type: oauth2
  flows:
  - flow: authorizationCode
    authorizationUrl: https://client.memo.bank/authorize
    tokenUrl: /oauth2/token
    refreshUrl: /oauth2/token
    scopes: 2
    scope_names:
    - AIS
    - PIS
  declared_in_spec: true
  defined_in_spec: true
  sources:
  - openapi/memo-bank-nextgenpsd2-api-openapi.yml
  note: >-
    The only securityScheme actually DEFINED in any Memo Bank OpenAPI document. Scopes are coarse, one per
    PSD2 service role.
- name: eIDAS certificate
  label: PSD2 third-party provider identification
  type: mutualTLS
  declared_in_spec: false
  sources:
  - openapi/memo-bank-nextgenpsd2-api-openapi.yml
  note: >-
    The NextGenPSD2 API follows Berlin Group Implementation Guidelines 1.3.11, which require a QWAC/QSEALC
    eIDAS certificate to identify the third-party provider. Recorded as a scheme because it is part of the
    regime the spec declares conformance to, though it is not expressed as a securityScheme in the document.
credential_provisioning:
  self_serve: false
  gate: >-
    A Memo Bank banker must activate the API feature on the workspace before any credential can be created.
  premium_bank_api:
    managed_at: https://client.memo.bank/api
    roles: Owners and administrators create applications and manage their permissions.
    collaboration: >-
      Collaborators can be invited per application to manage certificates, IP allow-lists and webhooks.
    artifacts_issued:
    - A certificate and its SHA-256 thumbprint
    - A secret code
    - An RSA private key
  marketplace:
    contact: openbanking@memo.bank
    applicant_provides:
    - A private key to sign request JWTs
    - The set of scopes the application needs
    - One or more redirect URIs
    artifacts_issued:
    - A certificate and its SHA-256 thumbprint
    - A secret code
    - A client ID
    - A client secret
    - A token used to authenticate Memo Bank's calls to the application's webhook
    guidance: Keep secrets secure and never expose them in client-side code.
additional_controls:
  ip_allow_list: Configurable per application.
  granular_permissions: Per-application permissions, managed by owners and administrators.
  two_factor: >-
    Required on the user sign-in step of the MCP connector OAuth flow, and on the web interface generally.
  mfa_app: Memo Bank Authenticator (iOS and Android).
gaps:
- >-
  components.securitySchemes is missing from the Premium Bank and Marketplace OpenAPI documents while every
  operation references an undefined `JWT` scheme.
- No PKCE documented on the authorization-code flow.
- >-
  No RFC 8414 authorization-server metadata is served, so the authorize and token endpoints cannot be
  discovered programmatically even though the MCP connector advertises RFC 9728 protected-resource metadata.
- >-
  NextGenPSD2 declares tokenUrl and refreshUrl as the relative path /oauth2/token rather than an absolute
  URL, which is ambiguous against the /nextgenpsd2-prefixed server base.
cross_links:
  scopes: scopes/memo-bank-scopes.yml
  conventions: conventions/memo-bank-conventions.yml
  well_known: well-known/memo-bank-well-known.yml
  mcp: mcp/memo-bank-mcp.yml