目次 1. 概要2. 認証・認可とは2.1. 認証2.2. 認可3. Salesforceにおける認証・認可とは4. OAuth2.0とは4.1. 概要4.2. 概要イメージ4.3. 各構成要素4.4. 認可コードフロー(Authrorization Code Grant Type)4.5. 認可リクエスト/認可レスポンスのイメージ4.6. トークンリクエスト/トークンレスポンスのイメージ4.7. その他のフロー5. OpenID Connectとは5.1. 概要5.2. フロー5.3. IDトークンとは6. SalesforceにおけるOAuth2.0/OpenID Connectとは6.1. 概要6.2. エンドポイント6.3. Salesforceでのフロー名とのマッピング6.4. 接続アプリケーション6.5. アプリケーションハンドラー7. 参考 概要 本記事では、業界標準であるOAuth2.0とOpenID Connectの概要を紹介した後に、Salesforceではそれらをどのように実装することができるのかを簡単に記載していきたいと思います。 本記事のベースとなるOAuth2.0やOpenID Connectの技術的な事項はこちらの本で学習しました。クライアント、認可サーバー、保護対象リソースのそれぞれについてサンプルのソースコードでどのように動作するかが詳細に記載されており理解するのに非常に役に立ちました。おすすめです。 認証・認可とは それぞれ詳細を説明すると非常に長くなるのですが、あえて一言で言うと下記で表せます。 認証 通信の相手が誰(何)であるかを確認すること 認可 とある特定の条件に対して、リソースアクセスの権限を与えること Salesforceにおける認証・認可とは Salesforceで実現可能な認証・認可の仕組みは下記が上げられます。 # 名称 概要 機能名 1 フォーム認証 Webブラウザでユーザ名とパスワードを入力する最も基本的な認証方式 標準ログイン画面 2 2要素認証 認証に2つ目の要素を追加することでセキュリティを強化する Salesforce Authenticator 3 SSO 一回の認証で複数のサービスを利用できる仕組みSalesforceは、IdpとSPのどちらになることもできる SAMLシングルサインオン 4 証明書認証 PCもしくはモバイルデバイスに配布されたクライアント証明書でログイン認証を行う 証明書認証 5 OAuth/OpenID Connect ←本記事ではこれを解説 外部アプリケーションにSalesforceのデータへのアクセスする際にその認可を与える仕組み 接続アプリケーション 6 Social Sign on ソーシャルアカウントで認証を行う 認証プロバイダ 7 代理認証 ユーザの認証を外部サービスで行う外部サービスはSalesforceが指定するWSDLに合わせたインターフェースを実装する必要がある 代理認証 OAuth2.0とは 概要 OAuth2.0は、業界標準でありRFCに下記のように定義されております。RFC6794(The OAuth 2.0 Authorization Framework)https://tools.ietf.org/html/rfc6749 ‘OAuth 2.0 は, サードパーティーアプリケーションによるHTTPサービスへの限定的なアクセスを可能にする認可フレームワークである. サードパーティーアプリケーションによるアクセス権の取得には, リソースオーナーとHTTPサービスの間で同意のためのインタラクションを伴う場合もあるが, サードパーティーアプリケーション自身が自らの権限においてアクセスを許可する場合もある. 本仕様書はRFC 5849に記載されているOAuth 1.0 プロトコルを廃止し, その代替となるものである.’ 言い換えると、下記のように表せます。 リソース所有者の代わりとして対象のリソースへのアクセスを許可するための手段 サード・パーティー製のアプリケーションがHTTPサービスへの制限されたアクセス権を取得できるするようにするためのもの OAuthとはシステムを構成しているある要素から別の構成要素にアクセス権を渡すためのもの では、なんのためにOAuthを使用して認可をするかというと サード・パーティ製のアプリケーションにユーザーの ID & パスワードを渡さない となります。 概要イメージ 0. まずユーザであるリソース所有者がクライアントのアプリケーションを使用します。1. クライアントは、保護対象リソースへアクセスするために一旦認可サーバーへリクエストを行います。2. 認可サーバーはリソース所有者との間でユーザ認証および認可を行います。3. 認可サーバーはユーザとの認証・認可が完了しているので、クライアントへアクセストークンを返却します。4. クライアントは、保護対象リソースへアクセストークンを利用してAPIアクセスを行います。 各構成要素 クライアント ・・・ ソフトウェアであり、リソース所有者の代わりとして保護対象リソースへのアクセスを行うもの 認可サーバー ・・・ OAuthの仕組みの中心的な役割を担うHTTPサーバーのこと. リソース所有者にクライアントを認可するための仕組みを提供し、トークンをクライアントに発行するもの リソース所有者 ・・・ クライアントにアクセス権を委譲する権限を持つ存在. ソフトウェアでなくユーザー. 保護対象リソース ・・・ HTTPサーバーから提供されており、そのリソースにアクセスするにはOAuthのトークンが必要となる. 保護対象リソースは提示されたトークンを検証して、リクエストに応えるかを判定する アクセストークン ・・・ 認可サーバーによってクライアントへ発行され、クライアントに権限が委譲されたことを示すもの スコープ ・・・ 保護対象リソースでの権限を表すものであり、クライアントに付与されるアクセス権限を制限するための仕組み リフレッシュトークン ・・・ 新しいアクセストークンを発行するために使用する 認可コードフロー(Authrorization Code Grant Type) OAuthのいくつかあるフローの中で最も標準的なフローである認可コードフローは下記のようになります。 認可リクエスト/認可レスポンスのイメージ response_type=codeで認可コードフローを指定 codeの値が発行された認可コード トークンリクエスト/トークンレスポンスのイメージ grant_type ・・・ authorization_codeで認可コードフローを指定。 その他のフロー # フロー名 概要 1 認可コードフロー(Authorization Code Type) 最も標準系のフロー。クライアントが認可コードを経由してアクセストークンを取得する。 2 インプリシットフロー(Implicit Grant Type) JavaScriptアプリケーション等で完全にブラウザ内で動作している場合に使用する。クライアントは認可エンドポイントから直接アクセストークンを取得する。 3 クライアント・クレデンシャルフロー(Client Credentials Grant Type) ユーザに関係なくクライアントアプリへ直接アクセストークンを発行する。 4 リソースオーナー・パスワード・クレデンシャルズフロー(Resource Owner Password Credentials Grant Type) 基本的に非推奨。(アンチパターン)アプリケーション側でID、PWを入力させて、それをトークンエンドポイントへ送り直接アクセストークンを取得する。 5 リフレッシュトークンフロー(Refresh Token Grant Type) リフレッシュトークンを使用して、アクセストークンの再発行を行う。 OpenID Connectとは 概要 OpenID Connect Core1.0https://openid.net/connect/ OpenID Connect 1.0 は, OAuth 2.0 … Continue reading SalesforceにおけるOAuth2.0/OpenID Connect