割と難しい
簡単にできるのかと思いきや、いろいろと知識がないと難しいです。とくにExpoやReactNativeだと通常のWebアプリに比べてややこしそうだという印象です。
Provider
Providerはソーシャルログインを提供しているサービスのことです。GoogleとかFacebook、Githubなど色々あります。まずはそれらのサービスに登録して、ログインサービスを動作させる設定をする必要があります。アプリの作成などといいます。OAuthやOpenIDといったキーワードで探すと見つかると思います。これらは各Providerによって設定方法や仕様が異なるので、マニュアルを熟読して理解する必要があります。
アプリ側
自分が作るアプリの方では、Providerで登録した際の情報を設定する必要があります。clientId, clientSecret, redirect_url, authorizationEndpointなどといったものになります。
リダイレクト先
Providerで認証処理が終わったら自分のアプリで受け取る必要がありますが、コールバックしてもらう場所になります。Webだと単なるURLなので難しくないです。 モバイルアプリだとリダイレクト先は端末内で動いているアプリになるので、bundleIdなど識別するものが必要です。DeepLinkingなどを理解する必要があるかもしれません。Expoだとまたややこしいのでくわしくはマニュアルを見る必要があります。
FirebaseAuth
FirebaseAuthにはソーシャルログインの機能があります。これはただExpoでは使えません。これを使えば簡単そうですが、試してません。
Expo
GoogleとFacebookは専用のライブラリが用意されています。他のは汎用ライブラリを使うことになりそうです。
- GoogleAPIの認証情報の画面でOAuth2.0クライアントIDを作成する
- ExpoのバンドルIDはhost.exp.exponentにして、使うプラットフォームごとに作成する(iOS, Android, Web)
- firebaseを使う場合は、firebaseコンソールでクライアントIDを許可する。
- Google.logInAsyncに渡す
AppAuth(汎用)
authAsyncにわたすconfigの設定が重要です。各Providerのサンプルは下記の通り。
コツはhost.exp.exponent://oauthredirect
をリダイレクトurlとして指定することです。
Provider側の画面でもこのリダイレクト先を許可しておく必要があります。
scopeでは利用許可する情報や操作の範囲を指定します。これはProvider 側の仕様書を確認する必要があります。
AppAuthは下記のライブラリがベースになっているので、ドキュメントが参考になります。
const githubAuthConfig = { scopes: ['read:user'], clientId: '<YOUR ID>', clientSecret: '<YOUR SECRET>', serviceConfiguration: { authorizationEndpoint: 'https://github.com/login/oauth/authorize', tokenEndpoint: 'https://github.com/login/oauth/access_token', revocationEndpoint: 'https://github.com/settings/connections/applications/<YOUR ID>', }, redirectUrl: 'host.exp.exponent://oauthredirect', };
- Slack
うまく動作しているように見える。
const slackAuthConfig = { scopes: ['identify'], clientId: '<YOUR ID>', clientSecret: '<YOUR SECRET>', serviceConfiguration: { authorizationEndpoint: 'https://slack.com/oauth/authorize', tokenEndpoint: 'https://slack.com/api/oauth.access', }, redirectUrl: 'host.exp.exponent://oauthredirect', };
AuthSession(汎用)
AuthSession - Expo Documentation AppAuthとは仕様が異なるみたいです。AppAuthの方が使いやすそうです。
まとめ
Webだともう少し簡単にできるのかも。ただ仕様の確認や動作確認やメンテナンスの手間を考えると、Auth0などのサービスを使ったほうが幸せなのかもしれない。
ログイン機能に手間を掛けるのは車輪の再発明に近いので避けたいが、ユーザーが経験するトラブルの代表格でもあるし、セキュリティの面からも品質を落とすわけには行かないから。