AuthRocket supports a growing number of social authentication providers. We’ve done all the hard work of integration and simplified everything into a single, unified API.
In fact, social auth requires no extra code beyond the small bit required to handle any kind of login. If you already have traditional, password-based logins working with AuthRocket, no additional code is required at all.
If you don’t have logins integrated with your app yet, don’t worry. It’s simple, and you’ll instantly have a variety of login and authentication methods available to you with a few clicks of your mouse (or trackpad).
AuthRocket’s social auth works with all types of logins: LoginRocket (hosted logins), authrocket.js, and self-hosted login pages.
If you’re using LoginRocket, when you enable a new AuthProvider, it automatically starts working.
For authrocket.js and self-hosted pages, you’ll just need to add one link for each social auth provider to your login page.
Mobile apps are supported both via webview or via native SDKs (where supported by the social login provider).
AuthRocket’s social auth support will always handoff a new social login as a normal login. The process is the same whether it’s the user’s first time to login with a particular social provider or a repeat login. As far as your app is concerned, it’s also the same whether they have logged in using a password or a different social provider in the past.
Everything arrives at your app as a simple, everyday login, including a new login session.
AuthRocket matches users based on email address. So if a user signs in via Facebook one day, and Google the next, as long as they used the same email address with both services, they’ll be treated as the same user.
If there’s not a matching user found, a new User will be automatically created. If your app is setup to receive webhooks, you will receive a user.created event.
After the first social login with a given provider, AuthRocket stores information about their social identity (as a Credential). The proper user will be matched to the same account in the future, even if their email address changes (at the provider or within AuthRocket).
When creating new users, AuthRocket always uses the email address for the username, even if the realm is not configured to require email-formatted usernames. In this case, the username can be safely changed later and will not break the link between that user and their social identity.
If not using LoginRocket’s login pages, you’ll need to add one or more links to your login form. You may want to add them to your signup form as well.
Each link is pretty simple:
<a href="https://yourapp.e1.loginrocket.com/auth/facebook">Login with Facebook</a>Let’s break this down. The link goes to your *.loginrocket.com address. If you have more than one Connected App, match the *.loginrocket.com address to the app the user is logging into.
The path always starts with /auth/. The ending can be either an Auth Provider provider_type or id. For more, see the LoginRocket API.
Of course, feel free to style your links as text, buttons, with each provider’s logo, or whatever is appropriate for your app.
/auth links require LoginRocket to be enabled. This is required for authrocket.js anyway, but may not be desired for self-hosted login forms. If you don’t want to enable LoginRocket, our API contains all the necessary methods to handle social auth without LoginRocket. See Auth Providers, especially Get an Auth Provider URL and Authentication with a Token.
Facebook and Google’s mobile SDKs both provide access to already authorized access tokens. You may send these tokens to AuthRocket for authentication.
See the Auth Provider API for details.
Questions? Find a Typo? Get in touch.