以下2冊のメモ
OAuth 2.0 と OpenID Connect は別物。
-
OAuth 2.0
- アクセストークン発行のための仕組み
誰がといった認証の部分は考えなくても良い。トークンによって何ができるか(認可)がわかればいい- なぜ必要?
- アクセストークンを使ってアクセスしたいサービスの ID / Pass を使う側のサービス(3rd party) が持たなくて済む
-
3rd party ライブラリで必要な権限のみ与えることができる(削除権限はもらわないなど)
- セキュリティ的なメリット
-
OpenID Connect
- ID トークン発行の仕組み
- 認証が伴う(ID なので)
- JWT が使われる(改ざん対策のためトークンには発行元の署名が必要なため)
SSO に使われるのは OpenID Connect の仕様のほう
OAuth Grant Type
| OAuth Grant Type/OAuthシーケンスに出現するか | リソースオーナーの同意 | 認可エンドポイント | トークンエンドポイント |
|---|---|---|---|
| 認可コードグラント | ○ | ○ | ○ |
| インプリシットグラント | ○ | ○ | X |
| クライアントクレデンシャルグラント | X | X | ○ |
| リソースオーナーパスワードクレデンシャルグラント | X | X | ○ |
クライアントクレデンシャルグラント に関しては、認可サーバーが提供するアクセストークンの権限はエンドユーザー単位ではない。
利用ユースケースとしては、ユーザ単位ではなく共通の権限でなにか別サービスを呼び出して何かしたい場合に利用する。そのため、必然的にリソースオーナーの同意は不要となる。
OAuth 認証
リソースサーバなどに認証ユーザの情報を取得するエンドポイントがある、かつアクセストークンでそのエンドポイントにアクセス可能な場合、該当エンドポイントをコールしユーザ情報を取得、認証情報を保存し認証済みとすることを指す。
そのため、アクセストークンを使ってユーザの情報を取得できるエンドポイントがないとこの仕組みを実装することができない。
所感
一番気をつけないといけなさそうなのは、アクセストークンの扱い。これが流出するとなりすましで認可されたユーザ以外がリソースにアクセスできるようになってしまう。
そのため、アクセストークンはなるべくサーバ側で持つようにしてクライアント側には返さないほうがよさそう。こういう場合は、key-value の形でアクセストークンを管理できるようにし、クライアントには key のみひとまず返せばいいのだろうか。
結局 key が漏れればアクセストークンが漏れると同義なような気はする。しかし、key を使ってアクセスできるapiしか操作できないので被害は小さくできている。
OpenID Connect までいくと ID token をしっかり検証していればセキュアに認証させることはできそうに思った。
簡易シーケンス
