OAuth? OpenID Connect?複数のサービスのアカウントを共有するには

はじめに

自社でシステム開発している複数のサービスを繋ぐこととなり、アカウントを共有したいニーズが出てきたので、アカウント用のサービスを作成することとなった。調べていくとOAuth2.0とOpenID Connectという言葉が出てきて似たような説明が多くされていたので整理する。

OAuth2.0とは

まず公式ドキュメントから引用するとこうなる。

OAuth 2.0 は, サードパーティーアプリケーションによるHTTPサービスへの限定的なアクセスを可能にする認可フレームワークである. サードパーティーアプリケーションによるアクセス権の取得には, リソースオーナーとHTTPサービスの間で同意のためのインタラクションを伴う場合もあるが, サードパーティーアプリケーション自身が自らの権限においてアクセスを許可する場合もある. 本仕様書はRFC 5849に記載されているOAuth 1.0 プロトコルを廃止し, その代替となるものである.

要点としては下記である。

• 認可フレームワークであること
• サードパーティアプリケーションに権限を与えるもの

参考にさせていただいたこちらの記事にも書いてあるが、認証ではなく認可の仕組みであるということはOAuthとOpenID Connectを理解する上で重要なことである。

また、2.0となっているのは1.0から色々仕様が更新された結果である。

認可と認証

こちらに関してはこの記事がわかりやすかった。とはいえまずは辞書を調べたところ、

認証とは・・・一定の行為または文書が正当な手続・方式でなされたことを公の機関が証明すること 認可とは・・・それを認めて許可すること

ここからシステムよりに言葉を変えると 認証とは・・・正当な手続きを踏んで、承認されたことをシステムが証明すること（Basic認証、生体認証等） 認可とは・・・ある事柄をシステムが許可すること（アクセストークン等）

OpenID Connectとは

こちらも公式ドキュメントより引用すると

OpenID Connect 1.0 は, OAuth 2.0 プロトコルの上にシンプルなアイデンティティレイヤーを付与したものである. このプロトコルは Client が Authorization Server の認証結果に基づいて End-User のアイデンティティを検証可能にする. また同時に End-User の必要最低限のプロフィール情報を, 相互運用可能かつ RESTful な形で取得することも可能にする. この仕様は, OpenID Connect の主要な機能である OAuth 2.0 上で End-User の情報伝達のために Claim を用いる認証機能 を定義する. この仕様はまた, OpenID Connect を利用するための Security, Privacy Considerations を説明する.

要点としては下記である。

• OAuth2.0にアイデンティティレイヤを加えたものである
• 認可サーバーの認証結果に基づいてユーザーを特定・識別しプロフィール情報を相互運用で取得する

つまりOAuthでは認証に関して何もなかったが、ざっくりOAuthに認証を加えたものがOpenID Connectである。

まとめ

以上より、私が実現したいことはOAuthではなくOpenID Connectで実現することだと理解できた。似たような言葉であるが、できた経緯や中身を知ることで今後誰かに説明するときに言葉の使い分けができる。ＩＴの世界では言葉の定義があやふやなことが多いのでできるだけ気を付けて発信するようにしたい。