縁側でお茶飲んだりして過ごしたい

日常の記録。ジャンルフリー。

#ochacafe 5(避けては通れない 認証/認可)に行ってきました

勉強会 Oracle ochacafe 認証 認可 OAuth

OCHaCafeの第5回に行ってきました。

ochacafe.connpass.com

今回は認証と認可に関するお話で、OAuth2.0やOpenIDConnectを例に説明してくれました。
OAuthについては、以前軽く調べたことがありましたが、サイトごとに言ってることが異なり、結局よくわからずじまいでした。

学んだこと

認証と認可の仕組み

仕組みとしては大きく2つ。

  1. SAML2.0
    ActiveDirectory FederationService(AD FS)と連携してSSOの設定をしたりする等、エンタープライズ向け
  2. OpenIDConnect
    他社サービス間で、JSONやRESTベースのメッセージ連携を行う等、コンシューマ向け
    OpenIDConnectは、OAuth2.0の拡張
    OAuth2.0自体は、システム間での情報の共有や認可を行う仕様

認証と認可の違いは、下記の通り。

  • 認証
    認証処理をしたときに確定されたユーザ情報を相手に提供すること
  • 認可
    ユーザが、システムに対して自分のリソースにアクセスすることを許可すること

混同しやすいけど、よくよく漢字の意味を考えたらその通りだなって思いました。
OpenIDConnectは、認証+認可に加えて、ユーザ情報をもっているらしい。

OAuthの認証、認可のフロー

例をもとに説明してくれました。
登場人物は4つ。

  1. リソースオーナ -> 自分
  2. クライアント -> 街の写真屋の印刷サービス
  3. リソースサーバ -> 写真共有サイト
  4. 認可サーバ

認可、認証フローはこんな感じらしい。

  1. まず自分が、印刷サービスを通じて、写真共有サイトから写真を見ようとする(「連携する」ボタンとか)。
  2. すると、認可サーバにリダイレクトされ、ログイン画面が出力される。
  3. ログインすると、印刷サービスに権限与えるよっていう画面が出力される。
  4. OKすると、認可コードが払い出され、そのまま印刷サービスにリダイレクトされる。
  5. 印刷サービスは、払い出された認可コードを利用して、認可サーバにアクセストークンのリクエストをする。
  6. 認可サーバは、認可コードが正しければ、アクセストークンを印刷サービスに払い出す。
  7. 印刷サービスは、アクセストークンをヘッダ等に付与して、写真共有サイトのAPIをコールする。
  8. 写真共有サイトは、アクセストークンを検証して、正しければ写真を返す。

アクセストークンの検証方法は2通りあるとのこと。

  1. JWT(JSON Web Token)であれば、写真共有サイト自身で検証可能、なぜならBase64だから。
  2. 認可サーバの検証機能を利用する。認可サーバは検証機能のエンドポイントを作るのが規定らしい。
    調べたら、作ることは規定ではなさそう。聞き間違い？RFC7662 OAuth 2.0 Token Introspection

ただし、上記フローには注意点があり、認可コードが盗まれたら、誰でもアクセストークンを取得できてしまう。
そのため、RFC7636 Proof Key for Code Exchange by OAuth Public Clientsがあるらしい。
このフローは、下記の通り。

  1. クライアントは、code_challengeというチャレンジコードを発行し、code_challenge_methodという暗号化方式とチャレンジコードを認可サーバに送る。
  2. 認可サーバは、チャレンジコードと、暗号化方式を認可コードと紐づけて保存し、認可コードを返却する。
  3. クライアントは、暗号化方式に従ってチャレンジコードからcode verifierという検証用コードを発行する。
  4. クライアントは、認可コードと検証用コードを紐づけて認可サーバに送る。
  5. 認可サーバは、送られてきた検証用コードから暗号化方式に従ってチャレンジコードを作成し、保存していたチャレンジコードと突合する。合致し、かつ認可コードも正しければ、アクセストークンをクライアントに返却する。

ややこしい。。。

以上がOAuthのフローとのこと。
ちなみに、OAuthのフロータイプは全部で6種類あるらしい。多い。。。

  1. 認可コードフロー
  2. インプリシットフロー
  3. リソース・オーナー・クレデンシャルフロー
  4. クライアント・クレデンシャルフロー
  5. アサーションフロー
  6. デバイスコードフロー

OpenID Connectのフロー

OpenID Connectは、追加でIDトークンを発行し、IDトークンを使い回すことで、別クライアントとのID連携ができるようになる。フローは、こんな感じになる。

  1. ユーザは、印刷サービスサイト上でログインボタンを押す。
  2. 認可サーバにリダイレクトされ、ログイン画面とともに認可していいかが問われる。
  3. ログインすると、認可コードが発行され、印刷サービスサイトにリダイレクトされる。
  4. 印刷サービスは、認可サーバに認可コードを送り、正しければIDトークンとアクセストークンが作成され、印刷サービスに返却される。
  5. 印刷サービスは、IDトークンから対象ユーザ、宛先、有効期限、署名を検証する。
  6. 印刷サービスは、認可サーバにアクセストークンを付与したユーザ情報取得リクエストを行う。
  7. 認可サーバは、必要に応じて追加のユーザ情報を返却する。
  8. 印刷サービスは、ログイン状態を作成し、ユーザはログイン完了となる。

普段何気なく利用している裏でこんなことが行われていたんですね。

さいごに

今まで何となくでしかわからなかったけれども、今回のOCHaCafeを通じて何となくから大体わかるようになりました。
次回は最終回で、5/10(金) OpenAPIのエコシステムについてです。参加予定です。

ochacafe.connpass.com