Auth

業務にて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側が確認できるようになる。 ...