釣りキチプログラマー翔平の備忘録 
はじめに
認証と認可 Keycloak入門の第３章 SSOの基礎知識を読んで、
実際にKeycloakを業務で利用している自分の観点で重要だと感じた、
SAMLとOIDCの違い、SSOの実現方式についてポイントをまとめました。
「Keycloakを導入検討していて、本を買って読んでみたけど理解が怪しい。。。」
という方に参考にして頂ければ幸いです。
2022/3/26追記
KeycloakでSpring Bootで作成したRestAPIを保護、
SPAにKeycloakのSSO機能でログイン機能を追加、
OIDCやOAuth2.0の違い解説などなどをまとめたまとめ記事を作りました。
興味のある方は是非みてください！！
keycloakでAPI保護・SPAログイン機能設定例、OIDC・OAuth・PKCE・認可コードフロー図解などまとめ
SSOのメリット
複数のアプリケーションすべてにログインするの面倒！！
１つログインしたら他のアプリケーションはログインなしで利用したい。
という目的で作られた認証済みという状態を安全にアプリケーション間で受け渡す仕組みが、
SSO(Single Sign On)です。
SSOのメリットは以下のように、システムの利用者だけでなく管理者側にもあります。
- (システム利用者側)１つのユーザI Dとパスワードを覚えるだけで良い
- (システム利用者側)一度ログインすれば複数のアプリが利用できる
- (システム管理者側)パスワード管理が集約できて、攻撃対象範囲も１箇所にできる
- (システム管理者側)多要素認証など認証強度を上げる際に手が入るのは１箇所のみ
- (システム管理者側)パスワード忘れの問い合わせも減る
SSOを実現するための標準プロトコルとしては、
OIDCとSAMLがあります。
OIDCについてはこちらに特徴などまとめているので参照ください。
OAuthとOIDCの違い｜それぞれで登場する概念とIDトークンとアクセストークンなど解説
OIDCとSAMLの違い
OIDCもSAMLも認証結果を連携するための仕組みですが
OIDCはJSONベースのJWSであるIDトークンを発行し、
SAMLはXMLベースのSAMLアサーションを発行します。
ここが大きな違いです。
そのため、OIDCの方が以下の点でメリットがあり、
今後SSO実装する場合、OIDCでの実装が可能ならOIDCを採用する方が良いです。
- IDトークンはJSONベースで、現代の開発言語フレームワークで使いやすい(XML起因の脆弱性なども懸念)
- JSONはXMLと比べてデータ量が小さくパフォーマンス的にも有利
- OIDCはOAuthをベースにしておりAPI認可にも対応可能
SAMLもSAMLアサーション発行までのフローはOIDCとザックリ同じようなフローなので、
とにかくOIDC(もっというとOAuthの認可コードフロー)さえ押さえておけば十分だと思います。
アプリケーションタイプ別SSO実現方式
アプリケーションタイプと制約別にSSOの実現方式が異なります。
本ではいろんなパターンを紹介されてましたが、個人的によく使いそうなパターンだけピックアップしてまとめました。
アプリケーションタイプがSaaSの場合
SaaSなので、個別カスタマイズやライブラリを組み込んだりが難しいです。
そのため、SaaS標準で用意されていればOIDCやSAMLの設定をポータル画面などでポチポチやる。
難しそうなら、
代理認証エージェント自前で用意して、
SaaSでログインするタイミングで自動的に認証サーバにクレデンシャルを自動送信し、
認証結果を認証サーバとやり取りできる仕組みを作る必要があります。
個人的には、代理認証の方式採用しなくて済むようにSaaSを選びたいです、、、
従来型のモノシリックなWebアプリケーション場合
自前で作っているアプリケーションなのでカスタマイズが可能となりどんな方式でも使えます。
Keycloakや別のOSSで配布されている、認証クライアント用のライブラリを
組み込んで認証サーバとやり取りさせる方式だったり、
Webアプリケーションが複数あって、それぞれにSSOの仕組みを入れるのが面倒な場合は
全アプリケーションの手前にリバースプロキシを用意して、そこで認証サーバとやり取りさせる方式があります。
アプリケーションAだけでこの方式採用してるシステムに現場で出会ったことがあって。。。。
この本があればこんなことする人も出なかっただろうな、、、と思います。
SPAやネイティブアプリの場合
バックエンドを立てて認証サーバとやり取りできるなら、
従来型のモノシリックなWebアプリケーションと同じ考え方です。
(バックエンドを従来型のモノシリックなWebアプリとみなせば良いです)
一方、
バックエンドを持たないフロントエンドと認証サーバで直接やり取りするようなケースの場合、
フロントエンドにOIDC/SAMLのclientライブラリを導入して、
フロントエンドと認証サーバでやり取りすることになります。
まとめ
今回は認証と認可 Keycloak入門第３章を読んでみて、
特にSAMLとOIDCの違い、SSOの実現方式についてまとめました。
OIDCの方がIDトークンはJSONベースなのでサイズが小さく性能面で有利だったり、
OAuthの認可コードフローがベースなのでAPI認可にも適用できたりとメリットが多いです。
OIDCの適用が可能なら、OIDCを採用するのが良いでしょうね！！
SSOの実装方式としては、以下４つです
- 標準機能でOIDCやSAMLに対応していればそれを利用する方式
- 認証代理の仕組みを一から作る方式(これはやりたくない。。。)
- OIDCやSAMLのクライアントライブラリを入れる方式
- リバースプロキシを立ててそこにクライアントライブラリを入れる方式
今まで自分はネットで調べまくってこの辺りの情報を集めて現場でこねくり回してKeycloak使ってましたが、
この本が２年前にあれば。。。どれだけ楽だったか、、、
