0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

wip_OAuth,OIDC,SSOについて理解したこと纏めます

Posted at

#❏背景
案件で認証周りを見る機会があったので詳細に理解したい
【GOAL】
とりあえず案件内で出てきたワードについて「内容」「違い」を理解する

  • SSO
  • OIDC
  • OAuth
    ※詳細な仕様ではなく、ざっくり仕組みを理解することに重点を置く

#❏本題
##◆OAuth(2.0)
権限の受け渡し=認可 を行う仕組み
基本概念は以下

  • 1.あらかじめ信頼関係を構築したサービス間で
  • 2.ユーザの同意のもとに
  • 3.セキュアにユーザの権限を受け渡しをする

###★何ができるか
サービス間で認可情報を受け渡せると、あるサービスが別のサービスの情報を操作できるようになる。
これにより、例えば、instagramでfacebookでも同時に投稿できるようにするみたいなもの

###★実現方法
ID/PWをクライアントに渡すのではなく、ある情報に対しての操作権限と有効期限等を定義したアクセストークンを渡すことにより
実現させている。
→ これにより、「リソースへの権限を持ったクライアントのみ」リソースを取得できる
###★登場人物と流れ

  • ユーザ:一般ユーザ
  • 認可サーバ:サービスプロバイダへのリソースへアクセスする権限を与えるサーバ
  • サービスプロバイダ:リソースを持っているサービス(例示でいうinstagram)
  • クライアント:サービスプロバイダの情報にアクセスしたいサービス(例示でいうfacebook)

一つ一つ見ていく
image.png
0.事前準備
 クライアントがサービス情報を登録し、cliant_id(クライアント識別子)を取得。
1.ユーザがクライアントに認可が必要なアクションを起こす
 例示の場合、facebookで投稿 のようなもの。
2.クライアントが認可サーバに0で取得したcliant_idを付与して「認可要求」
 サービスプロバイダへのアクセストークンを渡す対象かをユーザに尋ねに行く。
「○○への権限を渡しますか?」画面の表出→サービスプロバイダのID/PWでログインののち、
 OK「認可承認」でアクセストークンを発行「認可成功」
3.クライアントがサービスプロバイダにアクセストークンを付与してリソースデータをリクエスト

##◆OIDC
Open ID Connectの略
認可と認証をサポートした仕組み
※OAuthでも、アクセストークンを取得する際に認可サーバ経由で**「認証」していなかったっけ(ログインって書いたし)?
→ この認証はアクセストークンを取得するためだけのものであり、アクセストークンからでは
だれ(エンドユーザ)がサービスプロバイダにアクセスしているのかがわからない。**
仮に、その一回取得したアクセストークンを別のユーザが使用してアクセスしにかかってもリソースをとってこれてしまう
=大きな問題
このため、サービスプロバイダにアクセスしにかかる際に、毎回**「確からしいエンドユーザ」「許可を得て」**いるのかを検証するにはOIDCの仕組みを利用しなければならない。 ...という自身の見解(ここがOAUthとの差分)

###★何ができるか
GoogleのID連携などにより、GoogleのIDを使って別サービスにログインできたりできる

###★実現方法
ある情報に対してのアクセストークンに加え、ユーザの本人証明としてID Tokenを渡すことで、実現させている。
→ これにより、「承認されたユーザ」が「リソースへの権限を持ったクライアントを使って」リソースを取得できる。
###★登場人物と流れ

  • ユーザ:一般ユーザ
  • OpenIDプロバイダ:サービスプロバイダへのリソースへアクセスする権限とID Tokenを与えるサーバ
  • サービスプロバイダ:リソースを持っているサービス(例示でいうgoogle)
  • クライアント:サービスプロバイダの情報にアクセスしたいサービス

一つ一つみていく
image.png
0.事前準備
 クライアントがサービス情報を登録し、cliant_id(クライアント識別子)を取得。
1.ユーザがクライアントに認可が必要なアクションを起こす
 例示の場合、googleでログイン のようなもの。
2.クライアントが認可サーバに0で取得したcliant_idを付与して「認可・認証要求」
 サービスプロバイダへのアクセストークンを渡す対象かをユーザに尋ねに行く。
「○○への権限を渡しますか?」画面の表出→サービスプロバイダのID/PWでログイン「認証」ののち、
 OK「認可承認」でアクセストークンとIDトークンを発行「認可・認証成功」
3.IDToken検証により改ざんがないかを確認
別ユーザがアクセストークンだけ取得してきた際に「別ユーザ」と認識できるように
アクセストークンとのマッピングで判断?(このあたりが理解しきれてないです)
4.クライアントがサービスプロバイダにアクセストークンを付与してリソースデータをリクエスト

##◆SSO
Single Sign Onの略
一つのID/PWで複数のサービスに同時にログインする仕組み。
→ Aサービスでログイン処理を済ませたのち、Bサービスを開いたらすでにログインされている!(ログイン不要)

wip*

###★実現方法

#❏まとめ
それぞれの違い、関係性について

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?