App Services Authentication Providers

Parent: MongoDB Atlas App Services · Published reference · snapshot 2026-10-02

Depth-first rabbithole dossier for App Services Authentication Providers; source-anchored research pack.

These notes link each claim to its source. A source may be a research report hosted on this site rather than the primary document. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.

Definitions

The ES256 key in the reports is the client secret you sign yourself (claim 54), not the token Apple returns. None of the four reports sources which algorithm Apple uses to sign its tokens, or how many keys Apple's JWKS holds. I believe from background knowledge that Apple signs with RS256, but none of the reports sources this. Until that is sourced, treat E:30's "Apple" example and E:48 as unverified. They may conflate the two Apple JWTs. [source]

Structure and components

**D10. Is email case-sensitivity correct?** - App Services treats the whole address as case-sensitive. - RFC 5321 §2.4 says the part before the `@` is case-sensitive but the domain is not. https://www.rfc-editor.org/rfc/rfc5321.html [source]
- https://www.mongodb.com/docs/atlas/app-services/authentication.md - https://www.mongodb.com/docs/atlas/app-services/authentication/email-password.md (also shared cache: ~/.global-ai-hub/research-tests/mongodb-full-frontier-20261002/full-frontier-run/shared-sources/.firecrawl/mongodb.com-docs-atlas-app-services-authentication-email-password.md) - https://www.mongodb.com/docs/atlas/app-services/authentication/api-key.md - https://www.mongodb.com/docs/atlas/app-services/authentication/custom-jwt.md - https://www.mongodb.com/docs/atlas/app-services/authentication/custom-function.md - [source]

How it works

**Out of scope** (handoffs at the end): Rules, Functions, Triggers, Device Sync, the Data API as a product, and the parent App Services platform. [source]
Same URL [M:81, E:40-41, P:46] 50. Google's `config.openId` setting: - It defaults to `false`. - When it is on, App Services can read no metadata fields. - Some SDKs require it, and others do not support it. [source]
71. The function receives the client's free-form `payload`. It must return a unique external-ID string, or `{id}`, or `{id, name}`; `name` becomes the display name. [M:100, P:39] 72. If the external ID is already known, that user logs in. If it is new, App Services creates the user without asking. [M:101, P:39] 73. If the function throws, the client gets `401 - Unauthorized` carrying the thrown message, so debug messages can leak to clients. [M:102, E:38, P:40] 74. App Services does "no data validation or authentication checks" for this provider, so all security lives in your function. A funct [source]
79. The Data API tries `Authorization: Bearer` first. If there is none, it falls back to credential headers: `email` and `password`, `apiKey`, or `jwtTokenString`. Browsers can use only Bearer, because CORS blocks credential headers. Bearer also has "higher throughput". https://www.mongodb.com/docs/atlas/app-services/data-api/authenticate/ [M:112, P:51] 80. Changelog: `apiKey` headers arrived on 30 Nov 2022, and Bearer auth for the Data API and HTTPS Endpoints on 25 Jan 2023. https://www.mongodb.com/docs/atlas/app-services/release-notes/backend.md [H:44, H:46] [source]
81. realm-web 1.7.0 (Feb 2022): linking an anonymous user to email/password returned 401 every time. https://github.com/realm/realm-js/issues/4371 [M:117] 82. realm-js (the report says "2.0.0"; it is likely realm-web): calling `linkCredentials` with a wrong password or unknown email looped forever on session refresh. The cause was an unconditional retry on 401. PR #6588 fixed it. https://github.com/realm/realm-js/issues/6586 [M:118] 83. realm-core 13.24.0: logging in again after the refresh token expired, without logging out first, crashed the app with `realm::MultipleSyncAgents: Multiple sync [source]
**D4. End-of-life date.** - The mechanism report calls the date unverified: the App Services deprecation page gives no date. - The history and practice reports quote 30 Sep 2025 from the Device SDKs deprecation page, and rxdb.info gives the same date independently. [source]
- **In scope:** the providers inside Atlas App Services authentication: Anonymous, Email/Password (`local-userpass`), API Key, Custom JWT (`custom-token`), Custom Function, Google, Apple. Also the limits that apply to every provider, such as session tokens, identity linking, and deleting or disabling users. - **Out of scope:** Rules and Permissions, Functions, Triggers, Device Sync, the Data API as a product, and the App Services platform in general. These belong to sibling or parent frontier items. - **Inherited and not repeated:** the provider list, App ID, the `providers.json` shape and the [source]
1. The auth providers are not a standalone service. MongoDB calls the Device SDKs "the primary entry point" for App Services Authentication and User Management, says the feature "will no longer be available when the SDKs reach end-of-life", and tells users to move to another auth service. https://www.mongodb.com/docs/atlas/app-services/deprecation/ 2. After end of life, Authentication Triggers no longer run on login or create events, so any logic that lived in them must be rebuilt in the replacement system. https://www.mongodb.com/docs/atlas/app-services/deprecation/ 3. MongoDB gives no provid [source]
1. The final App Services docs list eight providers with these type strings: Anonymous `anon-user`, Email/Password `local-userpass`, API Key `api-key`, Apple ID `oauth2-apple`, Google `oauth2-google`, Facebook `oauth2-facebook`, Custom JWT `custom-token`, Custom Function `custom-function`. — https://www.mongodb.com/docs/atlas/app-services/authentication.md 2. No generic "OAuth2" provider exists. OAuth 2.0 is the protocol behind the three vendor-specific providers (Facebook, Google, Apple). The phrase "API key, JWT, OAuth2, Custom JWT" in the parent skill's trigger list overcounts: "JWT" and "C [source]
1. An authentication provider is "a modular service" that verifies identity; a user presents credentials to a provider, and on success the provider returns a unique identity and App Services logs the user in as the active user. (https://www.mongodb.com/docs/atlas/app-services/users/) 2. Every app must have at least one enabled provider; with no provider, no client application can connect. (https://www.mongodb.com/docs/atlas/app-services/users/) 3. On a user's first login with a provider, App Services creates an identity object holding a unique ID and provider-specific metadata; on later logins [source]
Handoff (siblings surfaced, not researched): App Services user objects and custom user data; Authentication Triggers; Data API authentication modes; Device SDK credential APIs. [source]
Product status: App Services is end-of-life. Every MongoDB page fetched on 2026-10-02 carries the banner "Atlas App Services has reached its end-of-life status and is no longer actively supported by MongoDB. Triggers remain available in the Atlas UI." (https://www.mongodb.com/docs/atlas/app-services/authentication/) [source]
- C38. "Atlas App Services does not perform any data validation or authentication checks for the custom function provider." Your function owns all checks, including password, 2FA and SSO. https://www.mongodb.com/docs/atlas/app-services/authentication/custom-function/ - C39. The function returns an external ID, either as a string or as `{id, name}`. An unknown ID creates a new user; a known ID logs that user in. The external ID is not the internal `user.id`. https://www.mongodb.com/docs/atlas/app-services/authentication/custom-function/ - C40. If the function throws, the client receives `401 - [source]
Out of scope (separate frontier items): Rules/Roles/Filters, Device Sync, the Data API and HTTPS Endpoints as products, Functions, Triggers, and the App Services platform as a whole. Inherited parent facts (App = deployment unit, App ID, the three parent doc URLs) are not repeated as findings here. [source]

Measurements and reference values

| Report | Passes | Final-pass rate | Own verdict | |---|---|---|---| | mechanism | 4 | 10% | soft stop | | history | 4 | 8% | budget exhausted | | edge-cases | 4 | 20% | budget exhausted | | practice | 4 | 11% | budget exhausted | [source]
| Report | New claims | Running total | Rate | |---|---|---|---| | mechanism | ~66 | ~66 | 100% (baseline) | | history | ~20 | ~86 | ~23% | | edge-cases | ~11 | ~97 | ~11% | | practice | ~6 | ~103 | ~6% | [source]

Problems, failure modes and limitations

**In scope:** - The provider types and the strings that identify them on the wire. - How a credential becomes an identity, then a user, then a session. - Each provider's settings, limits and failure modes. - How the provider set changed from Stitch (2017) to end-of-life (2025). [source]
1. **The parent's trigger wording overcounts.** It lists "API key, JWT, OAuth2, Custom JWT", but: - There is no generic OAuth2 provider. OAuth 2.0 is the protocol behind three vendor providers (Apple, Google, Facebook). - "JWT" and "Custom JWT" are the same provider, `custom-token`. - Source: https://www.mongodb.com/docs/atlas/app-services/authentication.md [H:16] - I did not edit the tree. Whether to fix the parent's wording is your call (see Needs input). 2. **The wire strings, session model, limits and failure modes** are all new here. The parent gave only the provider names, the header mod [source]
**A. Identity model** 1. A provider is "a modular service" that checks credentials. When it succeeds, it returns a unique identity, and App Services logs that user in. https://www.mongodb.com/docs/atlas/app-services/users/ [M:17] 2. An app needs at least one enabled provider. With none, no client can connect. https://www.mongodb.com/docs/atlas/app-services/users/ [M:18] 3. On a user's first login with a provider, App Services creates an identity holding a unique ID and provider metadata. Later logins refresh that data. https://www.mongodb.com/docs/atlas/app-services/users/ [M:19] 4. One user c [source]
19. A successful login returns `access_token`, `refresh_token` and `user_id`. The access token is a JWT. https://www.mongodb.com/docs/atlas/app-services/users/sessions/ [M:43] 20. Access tokens always last 30 minutes. A refresh is POST `.../auth/session` with `Authorization: Bearer <RefreshToken>`. Same URL [M:44-45] 21. Refresh tokens last 60 days by default. The app-wide setting accepts anything from 30 minutes to 5 years; the Admin API field is `expiration_time_seconds`. Same URL [M:46, E:24, P:32] 22. Anonymous refresh tokens "effectively do not expire". Same URL [M:47] 23. You cannot end [source]
30. Anonymous users have no metadata, and the provider has no settings. The same anonymous user is reused until an explicit logout. After logout, the old data cannot be recovered. https://www.mongodb.com/docs/atlas/app-services/authentication/anonymous/ [M:54-55, E:35, P:16] 31. A deleted anonymous account cannot be recovered. The documents it created or changed stay in the database. To keep the data, link the user to a permanent provider first. Same URL [M:56, E:36, P:40] 32. Failure mode (2020): in Realm Web, every page refresh created a new anonymous user. The older Stitch browser SDK had r [source]
34. Email addresses are case-sensitive: `[email protected]` cannot log in as `[email protected]`. [M:61, E:19, P:19] 35. Accounts are either Pending or Confirmed. A Pending account cannot log in, but it still reserves the email, so registering that email again fails. [M:62, E:20, P:20] 36. There are three confirmation modes: built-in email, a confirmation function, or `autoConfirm`. You use one, not several. [M:63] 37. Built-in confirmation and reset links work as follows: - Each link carries `token` and `tokenId` and expires after 30 minutes. - The email always comes from a `mongo [source]
[M:64, E:21, P:21-22] 38. A confirmation function can return three results: - `success`: the account is confirmed. - `pending`: the client must call `confirmUser`. - `fail`: no account is created, so the email can register again. [source]
[M:65, P:24] 39. The reset function's first argument is `{username, password, token, tokenId, currentPasswordValid}`. Any extra arguments from the SDK follow it. [M:66, P:26] 40. **Security trap:** `callResetPasswordFunction()` needs no authentication. If the reset function returns `success`, the password changes at once, so any caller can reset any user's password. The docs say to return `pending` instead. [M:67, E:22, P:25] 41. You can have a reset function or reset emails, not both. With a reset function configured, `sendResetPasswordEmail()` returns an error. [M:68, E:23] 42. `autoConfirm` [source]
https://www.mongodb.com/docs/atlas/app-services/authentication/api-key/ [M:73, P:27] 45. Key limits and rules: - Up to 100 server keys per app and 20 user keys per user. - Anonymous users cannot own keys. - Keys never expire on their own. - A server key's value is shown once and can never be retrieved again. - The provider must be enabled and deployed before you can create a key. - The provider has no settings. [source]
Same URL [M:82, E:42, P:45] 51. *Inference:* turning on OpenID Connect and domain restrictions together cannot work as documented. Domain restrictions need the email metadata field, and OpenID Connect gives no metadata at all. [E:78] 52. Google on iOS needs both a Web client ID and an iOS client ID, but the provider config must hold the **web** credentials. If you enter the iOS credentials, authentication fails. Same URL [M:83, E:39, P:43] 53. A field report confirms that failure: a user got error 47 `invalid id token: 'aud' must be a string containing the client_id`. https://github.com/realm/ [source]
https://www.mongodb.com/docs/atlas/app-services/authentication/apple/ [M:85, E:44, P:48] 55. One Apple provider serves either a mobile app or a web app, not both. The documented workaround runs Sign in with Apple manually, sends the result through Custom JWT, and links the identities. This was still an open SDK issue in November 2023. https://github.com/realm/realm-js/issues/6227 [M:86, H:41-42, E:43, P:47] 56. Apple shows its name-and-email consent screen only on the first authorization. If the app loses that data before saving it, the data does not come back unless the user revokes access to [source]
[M:90, H:39, E:29-30, P:32] 60. If a token's `kid` is not in the configured key set, validation fails. RFC 7517 says `kid` exists to choose among keys "during key rollover". https://www.rfc-editor.org/rfc/rfc7517.html [E:35] 61. By default `aud` must equal the App ID. You can instead configure a list of audiences and require "All" or "Any one" of them. Multiple-audience support arrived on 2 July 2021 (release-notes/backend.md). [M:91, E:33, P:35, H:43] 62. The identity ID comes from the JWT's `sub` claim. In the docs' example, `sub: "24601"` becomes `identities[0].id: "24601"`. [M:92] 63. App [source]
[M:95, E:32, P:34] 66. Since 13 Dec 2023, requests authenticated with Custom JWT also update `context.user.data` from the JWT. https://www.mongodb.com/docs/atlas/app-services/release-notes/backend.md [H:50] 67. App Services trusts any validly signed JWT and sets no rules on how the issuer authenticated the user; MFA, for example, is the issuer's job. Anyone holding a signing key can mint valid credentials. [M:96, P:31, P:37] 68. The Data API can auto-create a user from any valid JWT that matches no existing user. This works through the `jwtTokenString` header or a Bearer session token. [E:64] [source]
85. MongoDB announced Stitch on 20 June 2017. The release promised "integration with authentication providers". https://www.prnewswire.com/news-releases/mongodb-unveils-mongodb-stitch-the-new-backend-as-a-service-that-dramatically-simplifies-application-development-300476722.html [H:23] 86. TechCrunch's launch coverage listed Google and Facebook alongside service integrations (AWS, Twilio and others). It is not an authoritative list of auth providers. https://techcrunch.com/2017/06/20/mongodb-launches-stitch-a-new-backend-as-a-service-and-brings-atlas-to-azure-and-google [H:24] 87. The Stitch [source]
95. The Device SDKs were deprecated in September 2024 and reached end-of-life on **30 September 2025**. https://www.mongodb.com/docs/atlas/device-sdks/deprecation.md [H:80, P:14]. An independent site gives the same date, "End of life targeted for September 2025". https://rxdb.info/articles/alternatives/mongodb-realm-alternative.html [P:18] 96. The SDKs were "the primary entry point" for App Services auth, and that feature "will no longer be available" once they reached end-of-life. MongoDB named no replacement per provider; its advice was "contact your Account team". [E:16, E:18, H:81, P:15-16 [source]
**P. Migration constraints (only as they limit the providers)** [source]
99. Forum threads say the Admin API user listing exposes no passwords or hashes. The suggested workaround is to recreate users with random passwords and force a reset. *(Snippet only; the pages returned 403.)* https://www.mongodb.com/community/forums/t/export-app-users-passwords/300790 [P:52] 100. Firebase and Auth0, by contrast, document how to export and import password hashes. https://firebase.google.com/docs/cli/auth-import ; https://auth0.com/docs/manage-users/user-migration [P:53] 101. *Inference:* after 30 Sep 2025 a "lazy" migration is impossible, because the old login endpoint no long [source]
**D1. When are anonymous users deleted?** Three versions exist, all from MongoDB: - "inactive for 90 days" (anonymous/). - "may delete … 90 days old (or older)" (anonymous/, warning box). - "automatically deleted 90 days after they are created" (users/sessions/). [source]
**D8. Can `aud` be an array?** - The docs support several audiences. - A 2021 forum snippet says Auth0 tokens with an array `aud` failed unless sent through `jwtTokenString`. https://www.mongodb.com/community/forums/t/error-with-multiple-jwt-audiences/99508 [E:103] [source]
**D14. A copy error in the config reference.** The reference's row for `secret_config` says "The following provider configurations include `redirect_uris`". Which providers accept `secret_config` is therefore stated imprecisely. [M:131] [source]
**D16. Found during synthesis: do Apple tokens work through Custom JWT?** - The edge-cases report says ES256-signed tokens "(Apple …)" cannot go through Custom JWT, and that Apple's key cannot be rotated that way, because a JWK URI accepts only RS256. [E:30, E:48] - MongoDB's own documented workaround sends Apple's token through Custom JWT. [M:86, E:43, P:47] [source]
**Verdict: met for the concept as a whole, but weak for each claim.** The independent origins back the history dates, the end-of-life date, the RFCs behind D9 and D10, Apple's behaviour, and the migration contrast. Not one server-side limit or mechanism claim (sections B to J) has a source outside MongoDB. For those, MongoDB's docs remain the only authority. [source]
**Verdict: `BUDGET_EXHAUSTED` (soft stop), not `SATURATED-DEPTH`.** The merged rate falls steadily to about 6%. But no two consecutive passes fell below 5%, and no report reached saturation on its own. There was **no boundary breach**: the migration claims stop where they limit the providers. [source]
- App Services user objects and custom user data - Authentication Triggers (deprecated) - Authentication modes for the Data API and HTTPS Endpoints - The client-side credential APIs in the Device SDKs - Migrating App Services auth to an external identity provider [source]
- https://www.mongodb.com/docs/atlas/app-services/authentication/ (inherited) - https://www.mongodb.com/docs/atlas/app-services/authentication/email-password/ (inherited; cache: ~/.global-ai-hub/research-tests/mongodb-full-frontier-20261002/full-frontier-run/shared-sources/.firecrawl/mongodb.com-docs-atlas-app-services-authentication-email-password.md) - https://www.mongodb.com/docs/atlas/app-services/authentication/custom-jwt/ (inherited) - https://www.mongodb.com/docs/atlas/app-services/authentication/anonymous/ - https://www.mongodb.com/docs/atlas/app-services/authentication/api- [source]
1. **Should the parent's trigger wording be corrected?** It lists "JWT" and "Custom JWT" as two providers and "OAuth2" as a provider. Both are wrong (see "Changes this child adds" item 1). I didn't touch the tree. My default is to leave it for the tree-merge step. 2. **Should I write this dossier to a file?** I didn't, because I couldn't list the run folder to check what file name the batch expects. My default is no: the batch runner captures this output. 3. **D16 needs one source fetched.** Two edge-cases claims (E:30 and E:48) say Apple tokens can't go through Custom JWT, which contradicts M [source]
IN: the internal mechanism of Atlas App Services authentication providers. This covers the provider types and their wire identifiers, the credential each one accepts, how a credential becomes a user and an identity, the session tokens issued after login, the per-provider configuration schema, invariants and hard limits, and documented failure modes. OUT: Rules/roles, Functions in general, Device Sync, Data API beyond its auth headers, Triggers, and the parent App Services platform. Those are separate frontier items. Inherited parent facts (App ID, provider list in the brief) are not repeated a [source]
5. Access tokens always last 30 minutes. A Custom JWT `exp` does not change this. App Services checks `exp` only to confirm the incoming token is still valid before it issues its own 30-minute token. https://www.mongodb.com/docs/atlas/app-services/authentication/custom-jwt/ 6. A refresh token lasts 60 days by default. You can set the lifetime anywhere from 30 minutes to 5 years, inclusive. https://www.mongodb.com/docs/atlas/app-services/users/sessions/ 7. You cannot end one session on its own. You can only revoke all of a user's sessions. https://www.mongodb.com/docs/atlas/app-services/users/s [source]
- C50. A ranking of the providers by setup effort against control, built from C16–C48: Anonymous and API Key need no configuration. Email/Password is easy to start but needs custom functions to reach production quality. Custom JWT hands identity to an external IdP. Custom Function gives the most control and the most security responsibility (C38, C42). This ranking is synthesis. - C51. For the Data API, Bearer tokens beat credential headers. They have "higher throughput and [are] more secure," and only Bearer works from browsers, because CORS blocks credential headers. Custom JWT can authentica [source]
20. 2 July 2021: Custom JWT authentication gained support for JWTs with multiple audiences. — https://www.mongodb.com/docs/atlas/app-services/release-notes/backend.md 21. 30 November 2022: Data API requests could authenticate with `apiKey` credential headers. — https://www.mongodb.com/docs/atlas/app-services/release-notes/backend.md 22. 14 December 2022: refresh-token expiration became configurable through the Admin API. 16 March 2023 added the same setting to the UI. — https://www.mongodb.com/docs/atlas/app-services/release-notes/backend.md 23. 25 January 2023: Data API and HTTPS Endpoint req [source]
19. App Services compares the whole email address case-sensitively: `[email protected]` cannot log in as `[email protected]`. https://www.mongodb.com/docs/atlas/app-services/authentication/email-password/ 20. A user in the Pending state blocks anyone from registering that email again. A confirmation function that returns `fail` creates no account, so the same email can register again. https://www.mongodb.com/docs/atlas/app-services/authentication/email-password/ 21. Confirmation links and reset links both expire after 30 minutes. Built-in emails always come from a `mongodb.com` add [source]
29. With manual keys, only `HS256` and `RS256` are supported. You can set up to 3 signing keys. Each key must be 32–512 characters of ASCII letters, digits, `_` or `-`. https://www.mongodb.com/docs/atlas/app-services/authentication/custom-jwt/ 30. A JWK URI forces `RS256`. The JWKS can hold at most 3 keys, and every token must carry a `kid` header. So ES256-signed tokens (Apple, many IdPs' newer keys) and JWKS with more than 3 rotating keys cannot be used directly. https://www.mongodb.com/docs/atlas/app-services/authentication/custom-jwt/ 31. Size limits: a JWT can be at most 1,000,000 charact [source]
36. App Services does no data validation and no authentication checks for this provider. All of that is left to your function. https://www.mongodb.com/docs/atlas/app-services/authentication/custom-function/ 37. The returned value is an external ID, not the internal user ID. If the external ID is new, App Services creates a user without asking. So a function that returns attacker-controlled input (for example an unverified `payload.username`) lets anyone log in as, or mint, any identity. https://www.mongodb.com/docs/atlas/app-services/authentication/custom-function/ 38. A thrown error becomes ` [source]
35. Anonymous: no metadata and no configuration. If the app does not log the user out, the same anonymous user is reused. Linking to another provider persists the user's data. — https://www.mongodb.com/docs/atlas/app-services/authentication/anonymous.md 36. Email/Password: the user must be confirmed before login. Confirmation can be a confirmation email, a confirmation function, or auto-confirm. Auto-confirm is for development only. Confirmation and reset links expire after 30 minutes. Built-in emails always come from a `mongodb.com` address. Email addresses are case-sensitive. — https://www.m [source]
45. MongoDB deprecated the Atlas Device SDKs in September 2024. They reached end-of-life and were removed on 30 September 2025. — https://www.mongodb.com/docs/atlas/device-sdks/deprecation.md 46. Authentication and User Management was deprecated as part of the SDK deprecation. MongoDB named no replacement and told customers to "contact your Account team" to choose an alternative auth service. — https://www.mongodb.com/docs/atlas/device-sdks/deprecation.md 47. Authentication Triggers are deprecated, and they stop firing because App Services auth no longer exists. Database Triggers and Functions [source]
8. There are eight provider types, each with a fixed type string: `anon-user`, `local-userpass`, `api-key`, `oauth2-apple`, `oauth2-google`, `oauth2-facebook`, `custom-token` (Custom JWT), `custom-function`. (https://www.mongodb.com/docs/atlas/app-services/authentication/) 9. The realm-core client defines the same eight strings as `IdentityProvider` constants, for example `IdentityProviderCustom = "custom-token"` and `IdentityProviderFunction = "custom-function"`. (https://raw.githubusercontent.com/realm/realm-core/master/src/realm/object-store/sync/app_credentials.cpp) 10. In `/auth/providers [source]
43. For Google and Facebook, App Services receives the provider's OAuth 2.0 access token and uses it to identify the user and read approved profile data. (https://www.mongodb.com/docs/atlas/app-services/authentication/google/) (https://www.mongodb.com/docs/atlas/app-services/authentication/facebook/) 44. Google/Facebook config: `config.clientId`, `secret_config.clientSecret`, optional `metadata_fields` (`{name, required}`), `redirect_uris` (required for web; exact match incl. protocol and trailing slash), optional `domain_restrictions` (requires the email metadata field). (https://www.mongodb. [source]
50. Verification works in one of two modes. In manual mode you set `signingAlgorithm` `HS256` or `RS256` and list up to 3 signing keys as Secrets; each key uses only `[A-Za-z0-9_-]` and is 32–512 characters long. In JWK URI mode the JWKS must use `RS256`, include a `kid`, and hold at most 3 keys. (https://www.mongodb.com/docs/atlas/app-services/authentication/custom-jwt/) 51. App Services expects the `aud` claim to equal the App ID by default. You can instead configure a list of audiences and require either all of them or any one. (https://www.mongodb.com/docs/atlas/app-services/authentication [source]
67. MongoDB says the Device SDKs are the main entry point for App Services Authentication & User Management. That feature "will no longer be available" when the SDKs reach end-of-life, and authentication triggers are deprecated. (https://www.mongodb.com/docs/atlas/app-services/deprecation/) 68. MongoDB announced the deprecation of Device Sync in September 2024. (https://en.wikipedia.org/wiki/Realm_(database)) 69. The App Services Admin API and CLI are not deprecated as a whole. Their endpoints that depend on deprecated services are deprecated. (https://www.mongodb.com/docs/atlas/app-services/d [source]
- App Services user management & custom user data (custom_user_data.json, user creation function) - Authentication Triggers (deprecated) - Data API authentication / HTTPS endpoint auth options - Migration paths off App Services auth (provider-by-provider alternatives) [source]
In scope: the eight provider types, how each one authenticates, what each one stores, the limits each one imposes, the session tokens the providers issue, how they fail, and what their end-of-life means for operators. Out of scope: Rules/Roles, Functions in general, Triggers, Device Sync, the Data API as a product, and sibling App Services features. Data API material appears only where it limits how providers are used. Inherited parent facts are not repeated as findings. The parent already listed the provider types and the Bearer and credential-header auth model. [source]
- C1. MongoDB's docs now state: "Atlas App Services has reached its end-of-life status and is no longer actively supported by MongoDB. Triggers remain available in the Atlas UI." https://www.mongodb.com/docs/atlas/app-services/authentication/ - C2. Atlas Device SDKs were deprecated "as of September 2024" and reached end-of-life on **September 30, 2025**. https://www.mongodb.com/docs/atlas/device-sdks/deprecation/ - C3. The Device SDKs were "the primary entry point" for App Services Authentication and User Management. The deprecation page says this feature "will no longer be available when the [source]
- C12. Access tokens last 30 minutes. Refresh tokens default to 60 days. You can set the refresh lifetime anywhere from 30 minutes to 5 years, inclusive, and the setting applies app-wide. https://www.mongodb.com/docs/atlas/app-services/users/sessions/ - C13. Custom JWT is capped the same way. App Services "always specifies a 30-minute access token expiry even if the custom JWT token specifies a different expiry." It checks the external `exp` only to confirm the token is still valid. https://www.mongodb.com/docs/atlas/app-services/authentication/custom-jwt/ - C14. You cannot end a single sessio [source]
- C19. Email addresses are case-sensitive. `[email protected]` cannot log in as `[email protected]`. https://www.mongodb.com/docs/atlas/app-services/authentication/email-password/ - C20. A registered user is either Pending or Confirmed. A Pending account blocks re-registration of the same email. https://www.mongodb.com/docs/atlas/app-services/authentication/email-password/ - C21. There are three confirmation modes: built-in email, a confirmation function, or `autoConfirm`. Confirmation and reset links expire after 30 minutes. Custom subject lines are capped at 256 characters. https [source]
- C31. App Services does not care how the external system authenticated the user; MFA and other methods are the issuer's job. The token must be a signed JWT that contains a unique user ID. https://www.mongodb.com/docs/atlas/app-services/authentication/custom-jwt/ - C32. There are two verification modes. Manual keys accept `HS256` or `RS256` with up to three signing keys stored as Secrets; each key must be 32–512 characters of `[A-Za-z0-9_-]`. A JWK URI forces `RS256`, requires a `kid` header, and allows up to three keys. https://www.mongodb.com/docs/atlas/app-services/authentication/custom-jwt [source]
- **D1 — When anonymous users are deleted.** The sessions page says anonymous accounts are "automatically deleted 90 days after they are created" (https://www.mongodb.com/docs/atlas/app-services/users/sessions/). The anonymous-auth page says App Services deletes anonymous users "that have been inactive for 90 days," and in its warning box says it "may delete an Anonymous user object that is 90 days old (or older)" (https://www.mongodb.com/docs/atlas/app-services/authentication/anonymous/). The rules "90 days from creation", "90 days of inactivity" and "may delete" are not equivalent. I left th [source]
- **Independent hosts:** I used sources from mongodb.com docs (primary), github.com/realm issue trackers (field reports), rxdb.info, technetexperts.com, firebase.google.com and auth0.com. **The gate is met at ≥3 hosts, but only weakly.** Almost every mechanism claim (C7–C48) rests on MongoDB's own docs alone. The non-MongoDB sources confirm the end-of-life date, the `aud` failure modes and the migration constraints; they do not independently confirm the limits. The community forum and Medium pages (C36, C52, D4) were blocked (HTTP 403) and are cited from search summaries. - **Disconfirming sea [source]
- C43. Google needs a **web** OAuth client ID and secret, even for iOS apps. "If you add the iOS credentials instead, Google authentication will fail." https://www.mongodb.com/docs/atlas/app-services/authentication/google/ - C44. Field reports match that warning. A user who configured web credentials but sent a token minted for the iOS client ID got error 47: `invalid id token: 'aud' must be a string containing the client_id` (realm-swift #7658). https://github.com/realm/realm-swift/issues/7658 - C45. Google `openId: true` gives no access to metadata fields. "OpenID Connect support varies by S [source]
25. API keys never expire on their own. https://www.mongodb.com/docs/atlas/app-services/authentication/api-key/ 26. An app can have at most 100 server API keys. Each non-anonymous user can have at most 20 user API keys. Anonymous users cannot own API keys. https://www.mongodb.com/docs/atlas/app-services/authentication/api-key/ 27. A server key's value is shown once and cannot be retrieved later. The provider must be enabled and deployed before you can create a key. https://www.mongodb.com/docs/atlas/app-services/authentication/api-key/ 28. Ambiguity: the docs say API-key user objects have `typ [source]
39. The iOS app needs its own iOS client ID, but the provider must be configured with the *web* client credentials. If you enter the iOS credentials, Google authentication fails. https://www.mongodb.com/docs/atlas/app-services/authentication/google/ 40. A redirect URI must match exactly, including protocol and trailing slash. https://www.mongodb.com/docs/atlas/app-services/authentication/google/ 41. Domain restrictions only work if the email metadata field is set as required. https://www.mongodb.com/docs/atlas/app-services/authentication/google/ 42. OpenID Connect mode gets no metadata fields, [source]
43. One Apple provider can serve either a mobile app or a web app, not both. MongoDB's workaround is to run a manual Sign in with Apple flow for one of them, send that JWT through Custom JWT, and link the identities. https://www.mongodb.com/docs/atlas/app-services/authentication/apple/ 44. The client secret is an ES256 JWT that you sign yourself, valid for at most 6 months. MongoDB's sample script sets `exp` to 180 days. https://www.mongodb.com/docs/atlas/app-services/authentication/apple/ 45. Okta (2019) confirms the 6-month maximum and notes Apple shows the name and email consent screen only [source]
6. MongoDB announced Stitch, a backend-as-a-service, on 20 June 2017. The release promised "integration with authentication providers". — https://www.prnewswire.com/news-releases/mongodb-unveils-mongodb-stitch-the-new-backend-as-a-service-that-dramatically-simplifies-application-development-300476722.html 7. The 2017 launch named Google and Facebook among "pre-built integrations" with AWS, Twilio, Slack, Mailgun and PubNub. That list mixes service integrations and auth providers. It is not an authoritative auth-provider list. — https://techcrunch.com/2017/06/20/mongodb-launches-stitch-a-new-ba [source]
16. Stitch was rebranded into MongoDB Realm in June 2020. MongoDB Realm was renamed Atlas App Services in summer 2022. — https://www.mongodb.com/community/forums/t/is-realm-replacing-mongodb-stitch/5148 (search-result summary; the FAQ thread returned HTTP 403 to direct fetch) 17. MongoDB acquired Realm in spring 2019. In September 2023 the Realm database was rebranded "Atlas Device SDKs". — https://en.wikipedia.org/wiki/Realm_(database) 18. MongoDB announced the Realm → Atlas Device SDKs rename on 26 September 2023. — https://www.mongodb.com/company/blog/product-release-announcements/realm-now [source]
39. There are two kinds of API key. A server key is created from the CLI, API or UI, and creating it also creates a server user. A user key is created from an SDK for an existing non-anonymous user. (https://www.mongodb.com/docs/atlas/app-services/authentication/api-key/) 40. Limits: up to 100 server keys per app and up to 20 user keys per user. Keys never expire automatically. A server key's value is shown once and cannot be retrieved again. (https://www.mongodb.com/docs/atlas/app-services/authentication/api-key/) 41. API key users carry `type: "server"` in the user object, and rule or functi [source]
- C27. There are two kinds of key. Server keys are created via CLI, Admin API or UI, and each creates a server user; an app can have up to 100. User keys are created via SDK and belong to one non-anonymous user; each user can have up to 20. https://www.mongodb.com/docs/atlas/app-services/authentication/api-key/ - C28. "API keys do not expire automatically." A key's value is shown once at creation and cannot be retrieved later. The provider has no configuration options. https://www.mongodb.com/docs/atlas/app-services/authentication/api-key/ - C29. API key user objects have `type: "server"`. Rul [source]
14. Anonymous users have no metadata and no settings. After a user logs out, their earlier anonymous identity cannot be recovered. https://www.mongodb.com/docs/atlas/app-services/authentication/anonymous/ 15. If an anonymous account is deleted, it cannot be recovered. Documents the user created or changed stay in the database. https://www.mongodb.com/docs/atlas/app-services/authentication/anonymous/ 16. Anonymous refresh tokens "effectively do not expire". Instead, the account itself is deleted after 90 days. https://www.mongodb.com/docs/atlas/app-services/users/sessions/ 17. Failure mode: in [source]
- https://www.mongodb.com/docs/atlas/app-services/authentication/custom-jwt/ - https://www.mongodb.com/docs/atlas/app-services/authentication/anonymous/ - https://www.mongodb.com/docs/atlas/app-services/authentication/custom-function/ - https://www.mongodb.com/docs/atlas/app-services/authentication/api-key/ - https://www.mongodb.com/docs/atlas/app-services/authentication/google/ - https://www.mongodb.com/docs/atlas/app-services/authentication/apple/ - https://www.mongodb.com/docs/atlas/app-services/authentication/email-password/ (inherited cache) - https://www.mongodb.com/docs/atlas/app-servic [source]
The gate is **met, with a caveat.** The report uses sources on 7 distinct hosts: mongodb.com (docs, changelog, press release, blog), github.com (MongoDB's stitch-specifications and stitch-ios-sdk, plus realm/realm-js and realm/realm-kotlin issues), prnewswire.com, techcrunch.com, en.wikipedia.org, and sandrino.dev. The disconfirming search found that the "launched with Apple and custom-function" story does not hold up (see above). Caveat: almost all of the technical substance comes from MongoDB itself. The independent hosts back only dates, the launch framing, and one 2018 Custom JWT integrati [source]
26. Anonymous users have a unique ID but no metadata, and the provider has no configuration options. (https://www.mongodb.com/docs/atlas/app-services/authentication/anonymous/) 27. The same anonymous user is reused until explicit logout; after logout, the user cannot retrieve prior user data. (https://www.mongodb.com/docs/atlas/app-services/authentication/anonymous/) 28. Deleting an anonymous user does not delete documents that user created or modified. (https://www.mongodb.com/docs/atlas/app-services/authentication/anonymous/) 29. The SDK flag `Credentials.anonymous(reuseExisting = true)` was [source]
30. Email addresses are case-sensitive: `[email protected]` cannot log in as `[email protected]`. (https://www.mongodb.com/docs/atlas/app-services/authentication/email-password/) 31. Account states are Pending and Confirmed. A pending account cannot log in but still reserves the email, so re-registration fails. (https://www.mongodb.com/docs/atlas/app-services/authentication/email-password/) 32. Confirmation has three mutually alternative modes: built-in email, a confirmation function, or `autoConfirm`. (https://www.mongodb.com/docs/atlas/app-services/authentication/email-password/) [source]
63. The Data API tries `Authorization: Bearer <access token>` first. If no Bearer header is present, it falls back to credential headers: `email`+`password`, `apiKey`, or `jwtTokenString`. Credential headers fail from browsers because of CORS. (https://www.mongodb.com/docs/atlas/app-services/data-api/authenticate/) 64. For security, Bearer-auth errors are not detailed to the client; diagnosis requires the App logs. (https://www.mongodb.com/docs/atlas/app-services/data-api/authenticate/) [source]
- C16. Anonymous auth has no configuration options. The same anonymous user is reused until explicit logout. "Once a user logs out, the user cannot retrieve any previous user data." https://www.mongodb.com/docs/atlas/app-services/authentication/anonymous/ - C17. Anonymous refresh tokens "effectively do not expire." Account deletion is what limits an anonymous user's lifetime instead (see Disagreement D1). https://www.mongodb.com/docs/atlas/app-services/users/sessions/ - C18. Deleting an anonymous user does not delete documents that user created or modified. To keep the data, link the anonymous [source]

Comparisons and alternatives

Gaps that would still pay off, named by at least one report each: - The Facebook provider page, which was never fetched. - How the server handles Google `authCode` versus `id_token`. - Server-side limits on linking, such as a cap on the identities array. - Admin API rate limits on the auth endpoints, and which fields the user export includes. - The blocked forum threads (behind D8 and D15). - A dated Stitch changelog (behind D11 and D12). - Which algorithm Apple uses to sign its tokens (to settle D16). [source]
- **JWT length limit.** The changelog says the JWT length limit rose "from 2048 to 4096 characters" on 20 March 2024 (https://www.mongodb.com/docs/atlas/app-services/release-notes/backend.md). The Custom JWT page says "App Services limits the length of a JWT token to 1 million characters, and the length of each metadata field to 4096 characters" (https://www.mongodb.com/docs/atlas/app-services/authentication/custom-jwt.md). These may be different limits, such as the whole token versus a field, or a later raise. Neither source reconciles them. - **Anonymous user deletion trigger.** The Anonymou [source]
- **Anonymous user deletion trigger.** The Anonymous page says App Services deletes anonymous users "that have been inactive for 90 days" (https://www.mongodb.com/docs/atlas/app-services/authentication/anonymous/). The Sessions page says they are "automatically deleted 90 days after they are created" (https://www.mongodb.com/docs/atlas/app-services/users/sessions/). The two rules give different results for an active user older than 90 days. Not resolved. - **Logout vs. revocation semantics.** The Sessions page says logout "invalidates the refresh token". The same page also says deleting tokens [source]
- **When are anonymous users deleted?** MongoDB's own docs give three versions. Read them as separate claims; they do not average out. - "deletes anonymous user objects that have been inactive for 90 days": https://www.mongodb.com/docs/atlas/app-services/authentication/anonymous/ - "may delete an Anonymous user object that is 90 days old (or older)" (age, not inactivity; "may" rather than "will"): https://www.mongodb.com/docs/atlas/app-services/authentication/anonymous/ - "automatically deleted 90 days after they are created": https://www.mongodb.com/docs/atlas/app-services/users/sessions/ - T [source]

Facts and statements

9. The eight wire strings are `anon-user`, `local-userpass`, `api-key`, `oauth2-apple`, `oauth2-google`, `oauth2-facebook`, `custom-token` and `custom-function`. [M:27, H:15, P:25] 10. The realm-core client defines the same eight strings as constants. https://raw.githubusercontent.com/realm/realm-core/master/src/realm/object-store/sync/app_credentials.cpp [M:28] 11. In `/auth/providers.json`, a provider's `name` always equals its `type`. *Inference:* an app can have at most one provider of each type. https://www.mongodb.com/docs/atlas/app-services/reference/config/auth/ [M:29, H:17, P:26] 12. [source]
14. The login call is POST `<Base URL>/auth/providers/<ProviderType>/login`. The global base URL is `https://services.cloud.mongodb.com/api/client/v2.0/app/<App ID>`. https://www.mongodb.com/docs/atlas/app-services/users/sessions/ [M:35] 15. The docs list only five providers for direct HTTPS login: anon-user, local-userpass, api-key, custom-token and custom-function. The OAuth providers are not listed. [M:36, H:19, P:29] 16. realm-core sends a different body for each provider: - Anonymous: nothing. - Email/Password: `username` and `password`. - API key: `key`. - Custom JWT: `token`. - Custom F [source]
Source: the app_credentials.cpp URL above [M:37] 17. `.../app/<App ID>/location` returns `hostname` and `ws_hostname`. This is how a client finds a regional deployment. https://www.mongodb.com/docs/atlas/app-services/users/sessions/ [M:39] 18. The OAuth callback URL depends on region, either global or e.g. `us-east-1.aws.services.cloud.mongodb.com`. https://www.mongodb.com/docs/atlas/app-services/authentication/facebook/ [M:84] [source]
https://www.mongodb.com/docs/atlas/app-services/users/sessions/ [M:50] 29. Errors from Bearer authentication are not detailed to the client on purpose. Diagnosing them requires the App logs. https://www.mongodb.com/docs/atlas/app-services/data-api/authenticate/ [M:113, P:35] [source]
All claims in this section come from https://www.mongodb.com/docs/atlas/app-services/authentication/email-password/ unless they give another URL. That page is inherited from the parent. [source]
44. There are two kinds of key: - Server keys are made from the CLI, Admin API or UI, and each one creates a server user. - User keys are made from an SDK and belong to one existing non-anonymous user. [source]
Same URL [M:74, E:26-27, P:28] 46. API-key user objects carry `type: "server"`. Same URL [M:75, P:29] (but see disagreement D6) 47. The docs say not to use API keys in user-facing clients such as browsers. https://www.mongodb.com/docs/atlas/app-services/data-api/authenticate/ [M:76, P:30] [source]
48. For Google and Facebook, App Services receives the provider's OAuth 2.0 access token. It uses that token to identify the user and read the profile data the user approved. https://www.mongodb.com/docs/atlas/app-services/authentication/google/ [M:80] 49. Google and Facebook settings: - `config.clientId` and `secret_config.clientSecret`. - Optional `metadata_fields`. - `redirect_uris`, which web apps need. Each must match exactly, including protocol and trailing slash. - Optional `domain_restrictions`, which only works if the email metadata field is required. [source]
All claims in this section come from https://www.mongodb.com/docs/atlas/app-services/authentication/custom-jwt/ unless they give another URL. That page is inherited from the parent. [source]
59. There are two ways to verify tokens: - **Manual keys:** `HS256` or `RS256`, with up to 3 signing keys stored as Secrets. Each key is 32 to 512 characters drawn from `[A-Za-z0-9_-]`. - **JWK URI:** the JWKS must use `RS256`, every token must carry a `kid`, and the set can hold at most 3 keys. [source]
[M:94, E:31, P:33] (but see disagreement D3) 65. Metadata mapping: - Each mapping has `required`, a `name` (a path into the JWT in dot notation), and a `field_name`. - To match a literal dot in a claim name, escape it with `\`, as in `http://example\.com/id`. - If no `field_name` is given, the default is the last path segment. - App Services refreshes the metadata into `user.data` on every login. [source]
All claims in this section come from https://www.mongodb.com/docs/atlas/app-services/authentication/custom-function/ unless they give another URL. [source]
78. What each provider fills in: - Anonymous and Custom Function: nothing. - Email/Password: always `email`. - API Key: always `name` (the key's name). - OAuth providers and Custom JWT: only the fields you configure. [source]
https://www.mongodb.com/docs/atlas/app-services/authentication/ [M:108, P:28] [source]
**L. Credentials in headers (the Data API, only as it limits providers)** [source]
https://www.mongodb.com/docs/atlas/app-services/release-notes/backend.md [H:39, 45, 51, 53] 94. In September 2021 the Realm Kotlin SDK supported only Anonymous and Email/Password. A provider existing on the server did not mean every SDK supported it. https://github.com/realm/realm-kotlin/issues/463 [H:76] [source]
These give different results for a daily-active user. Under the inactivity rule the account lives forever; under the creation rule it is deleted on day 90. All four reports found this conflict. [M:128, H:89, E:95-99, P:95] [source]
**D2. Are anonymous users reused?** - The docs say the same anonymous user is reused until logout. - Two SDK issues report a new user on every login: realm-js #3164 and realm-core #7709. MongoDB closed #7709 "not planned". [M:130, E:100] [source]
**D5. Does revoking or disabling cut off access tokens already issued?** - The sessions page says logout leaves the server session alive for up to 30 minutes. It implies "Revoke all sessions" also kills access tokens, but no test confirms that. - The user-management page says disabling a user invalidates "existing access and refresh tokens". That supports immediate cut-off for disable, but not explicitly for revoke. [source]
**D6. What `type` does a user API key report?** - The docs say API-key user objects have `type: "server"`. - User keys belong to an existing person, so a rule that checks `type == "server"` may also match people who log in with their own key. [source]
**D7. Does "Any one" audience matching work?** - The docs offer "Any one" matching. - realm-js #4133 (Dec 2021) reported that it behaved like "All". The issue is closed, but the fetched page does not show a fix. https://github.com/realm/realm-js/issues/4133 [P:96] [source]
**D9. How does JWK URI verification actually work?** - MongoDB says it "passes the JWT and public key to the third-party provider's JWK API", which then "verifies the signature". - RFC 7517 defines no such API. A JWK Set is only a list of keys chosen by `kid`. [source]
The likely reality is that App Services fetches the keys and verifies locally. This is unconfirmed. [E:102] [source]
**D12. What did Stitch launch with?** - Secondary summaries (including GeeksforGeeks) say Stitch launched with Apple and Custom Function. - The July 2018 spec has neither, and Sign in with Apple did not exist until 2019. [source]
**D17. Found during synthesis: OAuth on the login endpoint.** - The docs leave the OAuth providers out of the direct HTTPS login list (claim 15). - realm-core still builds OAuth login bodies (`id_token`, `accessToken`, `authCode`) for the same endpoint pattern (claim 16). [source]
- **Inherited from the parent, not counted:** - https://www.mongodb.com/docs/atlas/app-services/authentication/ - https://www.mongodb.com/docs/atlas/app-services/authentication/email-password/ and its shared cache copy - https://www.mongodb.com/docs/atlas/app-services/authentication/custom-jwt/ [source]
Note that sections F and I (Email/Password and Custom JWT) rest almost entirely on these inherited pages. Their content is new, but their sourcing does not add a new origin. - **Non-inherited MongoDB-controlled sources** (one origin family): - Other mongodb.com doc pages, the changelog, the press release and the blog. - The prnewswire press release. - MongoDB's own GitHub repos: realm-core source, stitch-specifications, stitch-ios-sdk. - Issues filed by users on realm/* repos. These are independent field reports, even though MongoDB hosts them. - **Independent origins fetched directly (nine):* [source]
Run: /rabbithole, 2026-10-02. Concept: **App Services Authentication Providers** (parent: MongoDB Atlas App Services). [source]
31. 2018 Stitch spec: access tokens expired after 30 minutes. Refresh tokens were "permanent (until invalidated)". — https://github.com/mongodb/stitch-specifications/blob/master/source/sdks/sdks.rst 32. Final docs: access tokens still last 30 minutes. Refresh tokens default to 60 days and can be set from 30 minutes to 5 years. — https://www.mongodb.com/docs/atlas/app-services/users/sessions.md 33. Custom JWT always gets a 30-minute App Services access token, whatever the external JWT's `exp` says. App Services checks `exp` only to confirm the external token is still valid. — https://www.mongod [source]
13. The HTTPS login endpoint is `<Base URL>/auth/providers/<ProviderType>/login` (POST, JSON body of credentials); the global base URL is `https://services.cloud.mongodb.com/api/client/v2.0/app/<App ID>`. (https://www.mongodb.com/docs/atlas/app-services/users/sessions/) 14. The documented direct-HTTPS login list covers only `anon-user`, `local-userpass`, `api-key`, `custom-token`, `custom-function`; OAuth providers are not in that list. (https://www.mongodb.com/docs/atlas/app-services/users/sessions/) 15. realm-core serializes credential bodies per provider: anonymous sends no fields; email/pa [source]
57. The authentication function receives the client's free-form `payload`. It must return a unique external-ID string, or `{id}`, or `{id, name}` (`name` becomes the display name). (https://www.mongodb.com/docs/atlas/app-services/authentication/custom-function/) 58. If the external ID is already known, the matching user is logged in. If it is new, App Services creates a user, adds a `custom-function` identity, and logs the user in. (https://www.mongodb.com/docs/atlas/app-services/authentication/custom-function/) 59. If the function throws, the client gets a `401 - Unauthorized` that carries th [source]
- C7. Each provider has a fixed type string: `anon-user`, `local-userpass`, `api-key`, `oauth2-apple`, `oauth2-google`, `oauth2-facebook`, `custom-token` (Custom JWT) and `custom-function`. https://www.mongodb.com/docs/atlas/app-services/authentication/ - C8. "The `name` of an authentication provider is always the same as its `type`." The CLI stores provider config in `/auth/providers.json`. https://www.mongodb.com/docs/atlas/app-services/authentication/email-password/ - C9. One app can enable several providers. Client SDKs can link one user's identities across providers. https://www.mongodb.c [source]
**Read first:** App Services auth has reached end-of-life. Every MongoDB page carries the banner "Atlas App Services has reached its end-of-life status and is no longer actively supported by MongoDB." [M:11, H:84, P:13] Treat everything below as legacy behaviour: useful for understanding, auditing or migrating an existing app, not for designing a new one. [source]
In scope: the App Services authentication-provider subsystem itself. That covers the provider types and their wire identifiers, how each provider establishes identity, the session/token model they feed, how the provider set changed from MongoDB Stitch (2017) through MongoDB Realm (2020) and Atlas App Services (2022) to end-of-life (2025), and the primary sources for each step. [source]
62. Each provider fills a different amount of metadata. Anonymous and Custom Function users have none. Email/Password users always have `email`. API key users always have `name` (the key's name). OAuth providers and Custom JWT fill only the metadata fields you configure. (https://www.mongodb.com/docs/atlas/app-services/authentication/) [source]
- https://www.mongodb.com/docs/atlas/app-services/authentication/ - https://www.mongodb.com/docs/atlas/app-services/users/ - https://www.mongodb.com/docs/atlas/app-services/users/sessions/ - https://www.mongodb.com/docs/atlas/app-services/authentication/anonymous/ - https://www.mongodb.com/docs/atlas/app-services/authentication/email-password/ (shared cache: ~/.global-ai-hub/research-tests/mongodb-full-frontier-20261002/full-frontier-run/shared-sources/.firecrawl/mongodb.com-docs-atlas-app-services-authentication-email-password.md) - https://www.mongodb.com/docs/atlas/app-services/a [source]
**Practical implication:** the rest of this report describes legacy behaviour. Use it to understand, audit or migrate an existing app, not to design a new one. [source]
1. https://www.mongodb.com/docs/atlas/app-services/authentication/ 2. https://www.mongodb.com/docs/atlas/app-services/authentication/email-password/ (shared cache: ~/.global-ai-hub/research-tests/mongodb-full-frontier-20261002/full-frontier-run/shared-sources/.firecrawl/mongodb.com-docs-atlas-app-services-authentication-email-password.md) 3. https://www.mongodb.com/docs/atlas/app-services/authentication/custom-jwt/ 4. https://www.mongodb.com/docs/atlas/app-services/authentication/custom-function/ 5. https://www.mongodb.com/docs/atlas/app-services/authentication/api-key/ 6. https://w [source]

Related concepts

Authentication — is a part of App Services Authentication Providers
App — is a part of App Services Authentication Providers
Services — is a part of App Services Authentication Providers
Providers — is a part of App Services Authentication Providers

Children

No children recorded.

← the whole tree · 3D view· how to read this page