Migrating Authentication and Authorization from Atlas Device Sync to Ditto

this guide covers authentication and authorization (auth) flow in ditto, and the differences and similarities of auth processes used by mongodb atlas app services and ditto ditto auth flow components ditto the https //docs ditto live/install guides and https //docs ditto live/cloud services (backend) developers interact with ditto via the sdk on the device and via the https //portal ditto live/ in the cloud customer components the application (app), the authorization endpoint (a backend service), and the identity provider (idp) identity provider (idp) this is the service that manages user identities user logs in, and the idp issues them a token, that is used elsewhere in the system to represent that user idp can be either a fully managed third party service (for example auth0), or a service maintained by the customer the login method depends on user’s preferences and the idp's features and requirements—from straightforward username/password to social login with google or facebook, magic email links, multi factor authentication, and more authorization endpoint is a service deployed and accessible from the web; its url is stored in the ditto portal it’s responsible for assigning user access permissions to documents and collections in ditto, and validating user tokens auth flow sequencediagram actor user participant app as mobile app participant idp as identity provider participant ditto as ditto participant authendpoint as authorization endpoint %% authenticated session %% note over app,ditto authenticated flow user >> app chooses to log in app >> idp redirect to authenticate user >> idp enters credentials idp >> app return identity token app >> ditto login to ditto with identity token ditto >> authendpoint forward identity token authendpoint >> idp validate identity token authendpoint >> authendpoint assign authenticated permissions authendpoint >> ditto return jwt with permissions ditto >> ditto sign jwt ditto >> app establish authenticated session user >> app continues interaction app >> ditto sync data (authenticated permissions) ditto >> app to establish identity in the app, the user performs a login action with their identity provider the ditto sdk requires the user token to call the ditto login method when ditto login is called, ditto forwards the user token to the customer's authorization endpoint commonly, after login, the idp generates an identity token containing the user id and signs it with the idp's private key the https //jwt io/ format is commonly used the customer's authorization endpoint needs to accept http requests from ditto with the jwt as the payload, and verify the jwt's authenticity this is typically done by verifying the jwt's signature using the idp's public key, either via an sdk method or an api call to the idp's token validation endpoint respond to ditto with a new jwt containing permissions this jwt contains the read and write permissions for ditto collections specific to that user this often involves a database lookup for the user's role and set of permissions, and transforming them into ditto's expected format ditto backend will sign the received jwt with its own certificate and pass it back to the customer application this completes the login flow and allows the logged in user to interact with ditto differences and similarities between mongodb atlas app services and ditto implementations authentication atlas the now deprecated mongodb atlas app services bundled a way to access some identity providers and a permissions layer bundled idps included common providers like email and openid (such as google) ditto ditto doesn't bundle an identity provider; the customer always brings their own both many customers who operate their own custom idp would need to integrate it in both atlas and ditto authorization atlas permissions and roles were defined and stored directly in atlas, in mongodb's json like format ditto permissions are assigned via a webhook invocation from ditto to the customer's authorization service that returns a jwt with permissions to ditto user roles and permissions can be stored anywhere—for example, in the customer's own custom idp solution learn more https //docs ditto live/auth and authorization/cloud authentication https //docs ditto live/auth and authorization/shared key https //docs ditto live/auth and authorization/data authorization https //docs ditto live/auth and authorization/certificate based security