New Sign in with Slack button
everything you need to implement it quickly and effectively
Slack just launched their new “Sign in with Slack” button. With this new feature, you can:
- Sign in repeated users quickly. While with “Add to Slack” the user is always prompted to re-authorise your application, with this new button the user will only be prompted once and automatically sign in from then on. It’s more aligned to how other flows like Github and others work.
- Teams that only allow admins to install bots can still allow their users to sign in with their accounts, wich will allow you to authenticate new people.
- When signing in, you can request access to the users’ email or their team’s details.
With this post, you will learn some tips to get the best experience from this feature. You will also get some information about caveats from the new API on areas that might be confusing.
Tip 1: Skip the team select step when the user comes back
In Slack’s OAuth flow, you can pass an optional `team` parameter which will skip the step prompting the user to select the team they want to use.
When a user signs in with Slack, it’s a good idea to save a persistent cookie with the team id. On a repeated visit, if the user has that cookie, you will be able to send it to Slack and authenticate the user automatically without any extra interactions.
That cookie should be cleared when the user signs out of your application, so they can pick a different team.
Tip 2: Always let the user know what account they are using
Many users are part of more than one Slack team. If you are following step 1 and automatically singing the user in with the last team they signed into your application, they might not know which team it was.
Always show in your application what is the team and user they are signed in with.
Tip 3: Streamline the sign in process from links in your app’s Slack messages
When your bot posts a link to your application in a message, include the team id in that URL. That way, if a user clicks on the link, you can sign them in automatically with the right team skipping the team select step.
Tip 4: Allow users to upgrade their tokens
In Slack, each user has a unique access token for your application as long as the token is not revoked. When you go through new OAuth flows, new scopes can be added to that same token.
You can allow the users to grant your application or bot extra permissions after they are signed in just by going through the OAuth flow again, so you need to be able to support that.
Tip 5: Be aware of the user’s intent
Here’s an example with Slackline. When we show information about a shared channel, you get an “Add to Slack” button to join the channel directly. Be aware of the user intent and leverage the “Add to Slack” flow to sign the user in instead of forcing the user through both processes.
On a related point, you must assume users can have gone through the authentications in an order different from what you anticipated. Make sure you handle both cases: when a user completes a “Sign in with Slack” without previously completing “Add to Slack”, and the other way around.
This point is especially important given the differences between “Add to Slack” and “Sign in with Slack”, we will cover those in the next section.
Caveats
This new button is great, but there are some caveats that might make it confusing and which mean you cannot reuse your existing “Add to Slack” code directly for “Sign in with Slack”.
We want to cover some of these caveats, which will hopefully save you some time and head scratching.
Caveat 1: You need a different implementation from “Add to Slack”
When signing users in with “Add to Slack”, it’s common to rely on the API method `auth.test` to get the user and team IDs and then use `users.info` and `team.info` to fetch user and team details.
This will fail with “Sign in with Slack” since `auth.test`, `users.info` and `team.info` cannot be accessed with the sign in scopes. Instead, you need to use the `users.identity` API method to get those details.
To make things a bit more convoluted, the `users.identity` method is only available for the new sign in scopes. That means your sign in code needs to use different endpoints to fetch user details depending on the scopes your access token has access to.
Caveat 2: `users.identity` is a false friend of `users.info`
The new `users.identity` API method sounds pretty similar to `users.info` and might lead you to think they are related. However, they are pretty different.
As we mentioned in the previous scope, they require different scopes, but apart from that, the format of the `user` object in `users.info` is different to the one in `users.identity`.
The most notable differences:
- `users.identity` is missing `user.profile`, instead the `user.profile.email` is `user.email`
- `user.name` in `users.identity` is the equivalent to `user.profile.real_name` in `users.info` instead of `user.name`.
Caveat 3: You cannot get the user’s username
Following up on the last point from the previous list, “Sign in with Slack” will not grant you access to the user’s username, so your application must rely only on the user’s ID and real name.
If your application must have access to the user’s username, you will need a teammate to add your application to Slack with a `bot` or `users:read` scope and rely on `users.info` to get the username of the user.
Wrapping up
This new button is a great addition to the Slack platform. It will allow you to sign in more users and improve your application’s UX.
If you want to see it in action, you can check Slackline, and if you have any questions for us you can join our #siws-launch shared channel.
