To integrate your app or website with LastLogin, simply configure a
standard OpenID Connect provider, set the
the domain of your app (including the
client_secret blank. Make sure the
redirect_uri is on the same domain, ie
client_id must be a string prefix of
redirect_uri. This ensures security against phishing
attacks since the user will be shown your domain when they attempt
to log in.
What are the main ways LastLogin is different?
Many of the technical aspects are explained in the README for the obligator OpenID Connect server, which is the primary software LastLogin is built on.Here's a brief high-level list:
- Identity built on email. Email isn't perfect, but it's the decentralized global identfier we have today. LastLogin fully embraces email, and plans to add other forms of decentralized identity in the future, such as Matrix and ActivityPub.
- Very easy to integrate with. Standard OpenID Connect but you don't have to pre-register your client application. This means it also works great for software that is intended to be self-hosted.
- Designed for security. Tiny, focused codebase that avoids dependencies whenever reasonable (we don't roll our own crypto).
- Highly performant and scalable. It was designed from the ground-up to be globally distributed with minimal state. Almost everything is stored client-side in JWT cookies, which also improves privacy. We run on Fly.io, which puts our servers close to you and your users wherever you are.
- User-focused experience and features.
One of the reasons social login providers require client registration is for security. How is LastLogin secure if it doesn't do registration?
Another use of client registration is to allow an opportunity for developers to upload a logo and app name to be displayed to the user during login. This can actually create a serious security problem. If clients aren't properly vetted, any random app can display a logo for another organization. If users see the logo, they might not even look at the name of the app and just trust it. There have been real-world phishing attacks where the attackers used the app name "Google Docs" to gain access to many people's data.
Due to this, LastLogin's policy is that logos and app names are too dangerous to show during login. Only the domain (which is also used as the client_id) is displayed to the user in bold, and they must decide if they trust the domain.
Using the client's domain as the client_id has another advantage, which is that it's easy to validate the redirect_uri. We simply ensure that the client_id is a strict prefix of the redirect_uri, ie the redirect_uri is on the same domain as the client application. This general idea is described here.
Note that in the future we may offer pre-registration of clients in order to display a logo and name, but this will not be an automated process, nor a free one.
I develop software that is intended to be self-hosted. Does LastLogin benefit me or my users?
Yes. One of the core reasons LastLogin was built is because of how inconvenient it is to register current OIDC providers for each and every app you self-host, not to mention the privacy implications. With LastLogin, there is no registration step. Your self-hosted users can use LastLogin to sign in to their instances immediately, whether running on a custom domain or localhost.
And for those who prefer not to trusy any 3rd-party login provider, they can always self-host the software that LastLogin runs on and reap many of the same benefits.