どんまいこのネタ帳

花嫁修業だけでなくテックな修行のためアウトプットしていこうかと。ネットワーク/アプリ/サービスとりあえずなんでも

オッス！オラ認証周りをまとめてみた

一般的な基礎 AWS

こんにちは。今日は趣向を変えて千代田区立図書館に来てみました。

www.library.chiyoda.tokyo.jp

図書館は普段あんまり行かないので、地元の図書館との違いに驚きでした。 都内の図書館って広いし綺麗ですね。 九段下から割と近い、置いている蔵書のジャンルが多し、席のジャンル多し、無線Wifiあり、電源あり、でかなり使いやすかったです。 静かで落ち着いた雰囲気で過ごしやすい気がしますが、無音なので独り言が多い人は気をつけてください。

さて、前回の記事について@okeee0315さんからこんなコメントを。

ほほう。ADはまだ美味しくなかったので、教えに従い認証周りをもう少し調べてみることに。

認証と認可

指摘のあった認証と認可の違いから

  • 認証
    • Authentication
    • 本人確認
    • 本人を識別するIDとパスワードの対が一致することで本人とみなす処理
  • 認可(権限付与)
    • Authorization
    • 認証済みのユーザーに対しサービスの利用やリソースへの権限を与える処理

違いはこの図の感じ f:id:mnakajima18:20160504204054j:plain

この違いを知らなかったというより、まったく意識してませんでした。 ただ、この後の内容をやっていくうちに大きなポイントだったと知ることになります。

認証に関わるフェデレーションの技術とか

調べていく中で出てきた認証方式をつらつらと

  1. 認証API
  2. OpenID
  3. OAuth
  4. OpenID Connect
  5. SAML

1.認証API

  • 利用サイトにログインID/パスワードを入力しなくても認証情報提供サイトのログインID/パスワードで認証する仕組み
  • TypeKey認証、はてな認証API等、各社から認証APIは提供されている
  • 懸念点
    • 認証を特定のサービスに任せることの不安。こわい
    • 複数の認証APIに対応するには各々インターフェースを作りこむ必要がある。つらい

2.OpenID

  • 認証APIの懸念点を払拭した認証プロトコル
  • 分散認証型システムで複数の認証サービスを利用することができる
  • OpenIDの主な用語
    • OP(OpenID Provider):OpenIDによる認証サービスの提供者
    • RP(Relying Party):OpenIDによる認証を受け入れるサービス
    • Claimed Identifier:利用者のOpenIDアカウント名
  • OpenIDの認証の流れ
    1. ユーザはRPにアクセスし、自身のClaimed Identifierを入力する
    2. RPは入力されたClaimed Identifierを元にOPを探す
    3. RPはOPとの間で共通鍵を交換する
    4. RPはユーザをOPへリダイレクトさせ、ユーザの認証を要求する
    5. ユーザはOPにログインする。OPはClaimed IdentifierをRPに通知していいか確認する
    6. ユーザが同意するとOPは利用者をRPへリダイレクトさせ、認証結果をRPに通知する
    7. RPは受け取った認証結果に含まれるClaimed Identifierでユーザを認証する

3.OAuth

  • OpenIDの課題を解決するためにTwitter社のブレイン・クック氏をはじめとした開発者が集まりAPI認可プロトコルとして開発した
    • OpenIDはIDの持ち主が本人か確認(認証)してくれるが、認証されたIDがどのリソースにアクセスできるか(認可)はやってくれない
  • 認可(アクセス権限付与)のためのプロトコル。認証はないよ
  • OAuthプロトコルの特徴
    • API接続確認にトークンを使うこと
    • トークンはユーザーの同意に基づいてサービスプロバイダからサービスを提供するサイトに付与される
  • OAuthの用語
    • OAuth Server:OAuthをサポートしたAPIを提供しているサービス(OpenIDでいうOP)
    • OAuth Client:OAuth　Serverが提供するAPIを利用するサービス(OpenIDでいうRP)
    • Resource Owner:アクセス権限の付与を行うユーザー自身
  • OAuth 1.0と2.0の違い
    • OAuth 1.0の課題
      • 認証と署名の仕組みが複雑
      • Webアプリのみを対象としデスクトップ/モバイルアプリの対応が微妙
      • OAuth Clientがリクエストトークンの保管によりスケール時のパフォーマンス低下
    • OAuth 2.0の特徴
      • HTTPSを必須にし署名なしでトークン取得が可能
      • Webアプリ含め4つのクライアントプロファイルを仕様化
      • アクセストークンのみでリソースにアクセス可能

4.OpenID Connect

  • OAuth 2.0の拡張版
  • 認証も認可もやる。いいとこ取り
  • ユーザーの属性情報(ユーザー識別子、氏名、性別、生年、住所、メールアドレス等)を取得する機能も含む
  • こちらのスライドがかなりわかりやすい

www.slideshare.net

5.SAML

  • Security Assertion Markup Language
  • OpenID Connectに近い認証プロトコル
  • 認証情報の伝達(Authentication Assertion)、属性情報の伝達(Authorization Assertion)、アクセス制御情報の伝達(Authorization Decision Assertion)の機能をもつ
  • SAMLの用語
    • IdP(Identity Provider):認証情報を提供する側
    • SP(Service Provider):認証情報を利用する側
  • OpenID Connectとほとんど同じようだが、大きい違いは信頼関係の構築
    • SPが信頼するIdPの登録とIdPが信頼するSPの登録をそれぞれ行う
    • OpenID ConnectではSP(RP)がIdP(OP)に登録するだけだったはず
  • SAMLがエンプラ系で使われる理由かも
  • OpenID/OAuth/SAMLの違いをまとめているスライドがわかりやすい

www.slideshare.net

AWSのフェデレーションサービス

  • AD Connector:Active DirectoryのID/パスワードを使うなら
  • Amazon Cognito:ソーシャル認証プロバイダーのID/パスワードを使うなら

※Cognitoはもっといろいろ機能あるけどフェデレーションに絞るなら

西谷さんのためになる資料

www.slideshare.net

まとめ

バラバラと聞いたことある単語がようやく紐付いた感じ ちょっとActive Directoryが美味しくなってきたかもしれない、たぶん

参考資料