認証・認可のしくみとフロー(FIDO, OAuth, SAML)

Tue, 24 Nov 2020 14:51:59 +0900

業務にてOpen ID Connect(OIDC)を使った認証の仕組みを作ったが, いまだにOIDCがどういったものであるかを理解しないままだった。

そんな中, Software Design 2020年11月号にて認証・認可が取り上げられていたので, その中でOIDCについて詳しく書かれていた第2章ついてまとめる。

第2章認証・認可のしくみとフロー ~ FIDOからOAuth, SAMLまで一挙に解説 ~

ソーシャルログイン

外部のソーシャルネットワークサービス(Facebook, Twitterなど)を使って認証を行い, その結果をもって対象のWebサービスの認可を行う仕組み。対象のWebサービス側のID管理データベースへの新規登録を大幅に簡素化することができる。

Fast IDentity Online (FIDO)

生体認証を中心とする新しいオンライン認証技術。その名のとおり, 高速なオンライン認証を実現する。WebサービスではなくFIDO認証サーバで認証処理を行う。

Open Authorization (OAuth)

アプリ(Oauthクライアント)がユーザーの代わりにAPI(リソース)にアクセスすることを許す(権限移譲する)認可フレームワーク。これによって, Facebookにログイン(認証)したあとは, Instagramも利用(APIアクセスを認可)できるようになり, パスワードをサービスごとに設定・送信する手間から開放される。

OAuth 2.0

以下の点がOAuth 1.0と異なる。

Webサービスだけでなくスマホアプリも対象
アクセストークンを受け渡す仕組みを改善
HTTPSが必須

以下の4種類の認可フローが用意されている。比較的よく使われるのがAuthorization Code Grant。

以下がOAuth 2.0の仕組みである。スマホアプリは, 認可サーバの「認可エンドポイント」から認可コードを発行してもらう。次に, スマホアプリはアクセストークンを発行してもらうために, HTTPリクエストのペイロード部分に「grant_type=authorization_code&code=<認可コード>」という形で認可コードを入れ, 認可サーバの「トークンエンドポイント」に提出する。こうして取得したアクセストークンをHTTPリクエストのヘッダ部分などに「Authorization: Bearer <アクセストークン>」のように入れ, APIに提出する。

あくまで認可のしくみであり, 認証のしくみについては定義されていない。

リフレッシュトークン

アクセストークンを更新するためのトークン。

Webサービスは認証・認可のあと, HTTP Cookieによってユーザーを特定しているが, APIはトークンによって実行権限の有無を判定する。このトークンに, アクセストークンとリフレッシュトークンが含まれている。

OpenID Connect (OIDC)

認証結果を含むアイデンティティ情報も受け渡しできるようにOAuth 2.0を拡張したプロトコル。認証結果を含むアイデンティティ情報を「IDトークン」に入れて受け渡す。

アイデンティティ情報とはユーザーの属性情報や認証した日時などの情報であり, これをAPI側が確認できるようになる。

Auth on ashitaka blog