よりよくわかる認証と認可

早川貴裕

2020.12.24

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

少し早いですが、メリークリスマス！事業開発部の早川です。
早いもので、入社して 1 ヶ月半が経ちました。

現在は、 prismatix の理解を深めながら、導入支援を行っています。
今回はその中から、認証 / 認可についてお伝えします。

と言っても、これまでに同僚達が書いた分かりやすい記事がありますので、これらのガイダンスの形で、整理していきたいと思います。
ジョインしました以来、初めての記事となりますﾄﾞｷﾄﾞｷ

目標

本記事をご覧いただいた後、こちらのスライドを何となく理解できる~~気がする~~ことを目標とします。

マイクロサービス時代の認証と認可 - AWS Dev Day Tokyo 2018 #AWSDevDay from 都元ダイスケ Miyamoto

本スライドに関するブログ記事はこちらです。
AWS Dev Day Tokyo 2018 で「マイクロサービス時代の認証と認可」の話をしてきた #AWSDevDay

目的

まず、認証 / 認可を学ぶ理由を考えてみました。

近年、様々なサービスが API を通じてつながり、より便利な体験を受けられるようになっています。
一方で、この体験を安全に実現するための仕組みが必要になります。
利便性とセキュリティはトレードオフの関係にあると言われますが、これらの両立を目指す上で、認証 / 認可を避けて通ることはできず、学ぶ理由であると考えます。

よって、今回ご紹介する内容は、システムに関わるすべての方に意味があると考え、お伝えすることにしました。
それでは、本題に入ります。

Step 1 : 認証と認可の違いを知る

まずは、一緒に語られることの多い、認証と認可の違いを理解しましょう。
こちらの動画を、 6:00 くらいまでご覧いただくのがよいと思います。
(OpenID Connect や OAuth 2.0 などの言葉が出てきますが、この時点では無視していただいて大丈夫です。)

本動画に関するブログ記事はこちらです。
Developers.IO 2017セッション「基礎からの OAuth 2.0」でお話してきました #cmdevio2017

動画にあるように、認証と認可の違いは、以下になります。

認証とは、相手の身元を確認すること。
認可とは、権限を与えること。

これにより、以下の HTTP ステータスコードの違いについても理解できるようになります。

401 Unauthorized
- 認証の失敗 (お前誰だよ。)
403 Forbidden
- 認可の不足 (理解した。だが断る。)

ここまで理解いただいた上で、よくわかる認証と認可をご覧いただくと、さらに理解が深まります。
こちらの記事に合わせて、再度違いを確認します。

認証 (Authentication)
- 通信の相手が誰 (何) であるかを確認すること。
認可 (Authorization)
- とある特定の条件に対して、リソースアクセスの権限を与えること。

そして、記事にもあるように、認証と認可が一緒に語られるのは、以下の理由によると考えられます。

純粋な「認可」には「誰」という考え方はない、と言い放ちましたが、それでも多くの場合、認可は認証に依存しています。つまり「とある特定の条件」というのが「相手が特定の誰かであることが認証されている」という条件であることが多いのです。

さて、認証と認可の違いを理解いただけたでしょうか。
ここまで理解いただけたら、動画や記事の中にも登場した、 OpenID Connect / OAuth 2.0 に進みましょう。
(これまでより少し難易度が上がりますが、心を燃やしてがんばりましょう！)

Step 2 : OpenID Connect と OAuth 2.0 の違いを知る

それでは動画の続きをご覧ください。
といきたいところですが、少し難易度が上がりますので、先にまとめます。

OpenID Connect
- 認証の委譲の仕組み
- ID トークンという証明書を利用して、本人確認済みであることを証明します。
  (+ そのユーザーの属性 (プロフィール) 情報を知ることができます。)
OAuth 2.0
- 認可の委譲の仕組み
- アクセストークンという鍵を利用して、リソースへのアクセス許可 (錠を開ける権利) を管理します。

以上を意識した上で、動画の続きを 22:00 くらいまでご覧ください。

Developers.IO 2017セッション「基礎からの OAuth 2.0」でお話してきました #cmdevio2017 の「認可の委譲 (OAuth 2.0)」までを合わせてご覧いただくと、理解が捗ると思います。
(最後に OAuth 認証の話が出てきますが、この時点では無視していただいて大丈夫です。
OAuth を認可の仕組みとお伝えしましたが、 OAuth なのに認証 ? という混乱を防ぐためです。
OAuth 認証については、本記事の後半に参考記事を載せていますので、後ほどそちらをご覧ください。)

いかがでしょうか。
少し難しくなってきましたが、次が最後の Step です。
がんばって、責務を全うしましょう！

Step 3 : グラントタイプを知る

いよいよ最後です。
ID トークンやアクセストークンを取得するためのグラントタイプ (OpenID Connect ではグラントフローと呼ばれます) に突入します。

動画をご覧いただく前に、こちらも先にまとめます。
グラントタイプには、以下の 4 種類があります。

Client credentials grant
Resource owner password credentials grant
Implicit grant
Authorization code grant

それぞれの説明や流れについては、後ほど動画や記事をご覧いただきます。
ここでは、利用する立場から、それぞれを選択する場面をまとめておきます。

Client credentials grant
- 従来型のアプリケーション神パターン (管理画面など)
- ユーザーからの権限委譲が必要ない、アプリケーションが単独で実行し得るパターン (EC サイトでの商品情報の参照 / バッチ処理など)
Resource owner password credentials grant
- 公式アプリケーション (Twitter の認可サーバーを利用する場合の、公式 Twitter アプリなど)
- 利用は推奨されません。
Implicit grant
- モバイルアプリや JS アプリケーション等、エンドユーザーの支配下にあるノード上で動くアプリケーション
- 利用は推奨されません。
Authorization code grant
- OAuth の理想が詰まった、ユーザーからの権限委譲が必要な場合の推奨パターン
  (ご自身で学習を進めていただくと、 PKCE (Proof Key for Code Exchange) という言葉に出会うと思います。
  最近は、 Authorization code grant と PKCE を合わせたフローが推奨されています。)

それでは、以上を意識して、動画とブログ記事を最後までご覧ください。

(動画の 36:00 くらいまでをご覧いただき、その後を補足と捉えていただくのがよいと思います。
まずは、 36:00 までの内容を理解いただくことが大切だと考えています。)

お疲れさまでした！
以上で目標達成に向けた Step が完了となります。

ここまで理解いただけたみなさまなら、目標を達成できるのではないかと思います。
以下のスライドをパラパラと眺めてみてください。

目標が達成されるか確認する

マイクロサービス時代の認証と認可 - AWS Dev Day Tokyo 2018 #AWSDevDay from 都元ダイスケ Miyamoto

もし理解できる~~気がする~~ようであれば、立派に認証 / 認可の入り口に立たれていると思います。

理解できなくても、本記事でご紹介した動画や記事について、少しでも理解が深まり、今後サービスやシステムに関わる上でいかしていただければ、とても嬉しいです。
そして、またいつか読み返していただき、理解いただける日が来ることを祈っています。
(私も何度も動画を見たりしているのですが、その度に学びがあり、スルメイカのように味わっています。)

まとめ

認証 / 認可を学ぶ理由
- 利便性とセキュリティの両立を目指す上で、避けて通ることのできないテーマであるため。
認証と認可の違い
- 認証 (Authentication)
  - 通信の相手が誰（何）であるかを確認すること。
- 認可 (Authorization)
  - とある特定の条件に対して、リソースアクセスの権限を与えること。
    「とある特定の条件」というのが、「相手が特定の誰かであることが認証されている」という条件であることが多いため、多くの場合、認可は認証に依存している。
OpenID Connect と OAuth 2.0 の違い
- OpenID Connect
  - 認証の委譲の仕組み
  - ID トークンという証明書を利用して、本人確認済みであることを証明する。
    (+ そのユーザーの属性 (プロフィール) 情報を知る。)
- OAuth 2.0
  - 認可の委譲の仕組み
  - アクセストークンという鍵を利用して、リソースへのアクセス許可 (錠を開ける権利) を管理する。
グラントタイプの選択
- ユーザーからの権限委譲が必要な場合
  - Authorization code grant + PKCE を利用する。
- ユーザーからの権限委譲が必要ない場合
  - Client credentials grant を利用する。

理解を深めるための参考記事

本記事や、認証 / 認可に関する理解を深めていただくための参考記事をご紹介します。

OAuth 認証
- よくわかる認証と認可の「認可に基づく認証（！？）」の表現が分かりやすいと思います。
  この人は都元家の家のドアを開ける鍵を持っているから、都元さんである。
- 大まかには、以下のフローをもって、認証とする仕組みになります。
  1. OAuth で鍵を手に入れます。
  2. 手に入れた鍵を使って、プロフィール情報を取得します。
  3. 取得したプロフィール情報をもって、認証したことにします。
- さらに興味がある方は、以下をご覧ください。
  - OAuth 認証を真面目に考える
ログイン状態維持
- 本記事で得た知識をベースに、セッションやリフレッシュトークンについて学べます。
  - ユーザーをログアウトから守れ！―シーケンス図から読み解くログイン状態維持【Webアプリ編】
  - ユーザーをログアウトから守れ！―シーケンス図から読み解くログイン状態維持【Mobileアプリ編】
JWT
- IDトークンの形式である、 JWT について学べます。
  - JWTによるJSONに対する電子署名と、そのユースケース
その他に、認証 / 認可に関する素養を深めるために、以下のような記事もご利用ください。
- ログインにはなぜ username と password が必要なのか？〜簡単ログインを目指して
- やはりお前らの多要素認証は間違っている
  など。

この他にも、都元ダイスケが書いた参考記事がありますので、興味を持っていただいた方はぜひご覧ください。
(認証 / 認可以外もオススメです！)

最後に

prismatix について

prismatix では、 OpenID Connect と OAuth2.0 に準拠した ID 製品である Barista を実装し、 prismatix の各種 API をご利用いただく際の認証 / 認可基盤として提供しています。
(認証 / 認可の機能として、 Barista のみを導入いただいている事例もあります。)