To integrate your app or website with LastLogin, simply configure a standard OpenID Connect provider, set the client_id to the domain of your app (including the https://), and leave 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.

openidconnect.net is a great website for testing. See the steps in the repo to try it.

Developer FAQ

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:

One of the reasons social login providers require client registration is for security. How is LastLogin secure if it doesn't do registration?

The primary security advantage of client registration is providing a client secret to the client, and for the client to provide redirect URIs. When OAuth2 was initially designed, most apps had a backend component that could securely handle the secret. Nowadays many apps are purely frontend JavaScript, so client secrets can't be hidden. Newer methods such as PKCE (which is used by LastLogin) can be used to maintain security.

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 trust any 3rd-party login provider, they can always self-host the software that LastLogin runs on and reap many of the same benefits.