rfc6749とは？初心者向けに解説する OAuth 2.0の基本共起語・同意語・対義語も併せて解説！

この記事を書いた人

高岡智則

年齢：33歳性別：男性職業：Webディレクター（兼ライティング・SNS運用担当）居住地：東京都杉並区・永福町の1LDKマンション出身地：神奈川県川崎市身長：176cm 体系：細身〜普通（最近ちょっとお腹が気になる）血液型：A型誕生日：1992年11月20日最終学歴：明治大学・情報コミュニケーション学部卒通勤：京王井の頭線で渋谷まで（通勤20分）家族構成：一人暮らし、実家には両親と2歳下の妹恋愛事情：独身。彼女は2年いない（本人は「忙しいだけ」と言い張る）

rfc6749とは何か

rfc6749は、OAuth 2.0 の公式な標準文書の番号です。IETF が定めたもので、インターネット上のアプリ同士が安全に「誰が何をできるか」を決める仕組みを示しています。日常のウェブサービスでも、他のサービスに自分のデータを渡すときに使われる仕組みの土台となるため、初心者にも覚えておくと良い言葉です。

OAuth 2.0の基本的な考え方

OAuth 2.0 は、第三者アプリがユーザーの代わりに特定のデータへアクセスすることを許可する仕組みです。ユーザーは自分のアカウントをそのまま教えるのではなく、認証サーバーを通して「このアプリに限定して、データへのアクセスを許可してよいか」を判断します。

主な用語と役割

リソースオーナーはデータを持つ人やアプリのこと、クライアントはデータへアクセスしたいアプリ、認可サーバーは承認を出す機関、リソースサーバーは実際のデータを提供するサーバー、アクセストークンはアクセスの鍵のようなものです。

主な認証フロー（イメージ）

OAuth 2.0 にはいくつかの「フロー」と呼ばれる流れがあります。代表的なものを初心者向けにイメージで説明します。最初に大切なのは、セキュリティの高いサイトほどフローの選択が重要になる点です。

代表的な認証フロー

フロー	特徴	使いどころ
Authorization Code Flow	ユーザーが認証サーバーでログインし、承認コードを取得。その後アプリがこのコードを使いアクセストークンを取得する	サーバーサイドのウェブアプリで推奨
Implicit Flow	承認コードを使わず直接アクセストークンを取得する方法。近年は推奨されず、主に古いアプリで使われる	古いウェブアプリやSPAなど
Client Credentials	クライアント自身がデータへアクセスする場合に使用。リソースオーナーは関係しない	バックエンド間のサービス間通信
Resource Owner Password Credentials	ユーザーのIDとパスワードを直接クライアントに渡す方式。現代では非推奨	内部の信頼できるアプリに限り限定的に使用

補足として、PKCEは、公開クライアントでも安全に使える工夫です。承認コードに追加情報をつけて、悪意あるコードの盗用を防ぎます。これにより、スマートフォンアプリやウェブアプリでも安全性を高めることができます。

実務での使い方の考え方

実務では、あなたのアプリがどのフローを使うべきかを設計段階で決めます。たとえば、ウェブアプリがサーバー側で動く場合はAuthorization Code Flowが基本となり、モバイルアプリやJavaScriptだけで動くアプリにはPKCEを組み合わせた流れを選ぶことが多いです。

セキュリティのポイント

重要なのは、アクセストークンを安全に管理することです。アクセストークンはデータへアクセスする鍵なので、第三者に知られないように、送信時はHTTPSを使い、保存時も適切に保管します。リフレッシュトークンは長期間有効な場合があるので、適切にローテーションしたり、失効させたりする運用が必要です。

まとめ

このように rfc6749 は OAuth 2.0 の基本的な仕組みと流れを定義した文書です。初心者はまず用語と役割を覚え、実際のフローの流れをイメージしてから、必要に応じて PKCE などの追加的な安全対策を学ぶとよいでしょう。

rfc6749の同意語

RFC 6749: OAuth 2.0 の正式な仕様書の RFC 番号。IETF が公開した公式文書。
RFC6749: RFC 6749 の表記揺れ（スペースなしの名称）。意味は同じ。
The OAuth 2.0 Authorization Framework: OAuth 2.0 の英語正式名称。認可フローとアクセストークンの仕様を定義する文書。
OAuth 2.0 Authorization Framework: OAuth 2.0 の英語表現。RFC 6749 の正式名称を指す。
OAuth 2.0 認可フレームワーク: OAuth 2.0 の日本語での正式名称。
OAuth 2.0 認可仕様: OAuth 2.0 の認可に関する仕様を指す表現。
OAuth 2.0 仕様: OAuth 2.0 の仕様そのものを指す一般的な言い方。
OAuth 2.0 標準: OAuth 2.0 の標準的な仕様を指す表現。
RFC 6749 (OAuth 2.0): RFC 6749 が OAuth 2.0 の仕様であることを併記した表現。
RFC 6749の正式名称: RFC 6749 の正式名称を指す表現。
OAuth 2.0 のRFC: OAuth 2.0 が RFC 系の公式仕様であることを示す表現。
OAuth 2.0仕様書: OAuth 2.0 の公式仕様をまとめた文書を指す日常表現。
OAuth 2.0 認可フレームワーク（RFC 6749）: RFC 6749 として知られる OAuth 2.0 の正式名称を示す表現。

rfc6749の対義語・反対語

RFC6749準拠ではない: RFC6749（OAuth 2.0の標準仕様）に沿っていない、または標準フローを使用していない状態を指す対義語です。
OAuth 2.0を使わない認証認可フロー: OAuth 2.0以外の認証認可モデルを意味します。例としてSAMLなど、別の認証フレームワークを想起させます。
自前実装の認証・認可: 公的標準に沿わず、企業や組織が独自に設計・実装した認証・認可の方法を指します。
セキュリティ要件が低い認証フロー: 強度が低く、脆弱になりやすい認証設計を対外的に示す表現です。
トークン不要の認証フロー: アクセストークンを使わず、資格情報を直接検証する方式を意味します。
認証のみ・認可なしの設計: 身元確認だけを重視し、権限付与（認可）を伴わない設計を指します。
非標準・非準拠の設計: 公式RFCに準拠しない、非標準の認証・認可設計を表します。
SAML認証フレームワーク: OAuth 2.0の対義語として挙げられることのある、SAMLなどの別フレームワークを指します。
OAuth 2.0以外の認証認可フレームワークを使う選択肢: OAuth 2.0に依存しない、他の標準を用いる場合の総称として捉えられます。

rfc6749の共起語

OAuth 2.0: リソース保護のための認可フレームワーク。RFC 6749 によって定義される主仕様。
RFC 6749: OAuth 2.0 の正式な仕様番号。認可とトークンの取得の流れを規定する。
Authorization Code Flow: 認可コードを用いてアクセストークンを取得する、サーバーサイド向けの安全な認可フロー。
Implicit Flow: クライアント側アプリで直接アクセストークンを取得するフロー。セキュリティ上のリスクが高く、近年は推奨されないことが多い。
Client Credentials Flow: クライアントの認証情報だけでアクセストークンを取得するフロー。バックエンド間通信などで使われる。
Resource Owner Password Credentials Flow: リソースオーナーのユーザー名とパスワードを直接用いてトークンを取得するフロー。セキュリティ上のリスクが高く、推奨度は低い。
Access Token: リソースへアクセスするためのトークン。通常は期限付き。
Refresh Token: アクセストークンの有効期限が切れた場合に新しいアクセストークンを取得するための長期有効なトークン。
Bearer Token: アクセストークンの代表的な形。HTTP ヘッダの Authorization: Bearer 形式で送信されることが多い。
Token Endpoint: アクセストークンの発行・更新を行うエンドポイント。
Authorization Endpoint: 認可コードを発行するエンドポイント。ユーザーの同意を得る入口。
Redirect URI: 認可コードを返す際の転送先URL。事前に登録しておく必要がある。
Client ID: クライアントを識別する公開情報。アプリの識別子。
Client Secret: クライアントの機密情報。サーバー間の認証に使用される。
Scope: アクセス権限の範囲を表す。要求する権限を明示する。
PKCE: Proof Key for Code Exchange。公開クライアントでの認可コードフローのセキュリティを高める拡張。
Code Verifier: PKCE でコードを検証するためのランダム値。
Code Challenge: Code Verifier から派生させる値。サーバーが照合してセキュリティを高める。
Code Challenge Method: コードチャレンジの生成方法。代表的には S256（SHA-256）など。
OpenID Connect: OAuth 2.0 の認証機能を追加する仕様。ID トークンやユーザー情報を提供。
ID Token: OIDC で使用される、ユーザーを識別するためのトークン。
JWT: JSON Web Token。署名付き・暗号化されたトークン形式として広く用いられる。
JWS: JSON Web Signature。JWT の署名機能を表現する形式。
JWK: JSON Web Key。公開鍵の表現形式。
RFC 6750: Bearer Token Usage。ベアラートークンの取り扱いを規定する補足RFC。
Dynamic Client Registration: 動的クライアント登録。新しいクライアントを自動で登録する仕組み。
Revocation: トークンの取り消しを行う機能。トークンの失効管理をサポート。
Token Introspection: トークンの有効性・属性を照会して検証するエンドポイント。
Resource Server: 保護されたリソースを提供するサーバー。
Authorization Server: トークンを発行・検証するサーバー。
OpenID Discovery: OIDC のメタデータを自動取得する仕組み。

rfc6749の関連用語

OAuth 2.0: ウェブサービス間でのリソースアクセスを安全に認可するための標準フレームワーク。アクセストークンとリフレッシュトークンの発行・利用を規定します。
RFC 6749: OAuth 2.0 の正式仕様書。フローの定義、エンドポイント、トークンの取り扱いなど、実装時の共通ルールを示します。
Authorization Code Grant: ユーザーの認証を経て認可コードを取得し、それを使ってクライアントがアクセストークンを取得する安全性の高いフロー。クライアントサイドの機密情報を保護しやすいです。
Implicit Grant: クライアントに直接アクセストークンを返すフロー。ユーザーエージェント側のみで完結しますが、セキュリティ上のリスクが高いため現代では推奨されません。
Resource Owner Password Credentials Grant: ユーザーのIDとパスワードをクライアントが直接取得してトークンを得るフロー。セキュリティリスクが大きく、推奨されません。
Client Credentials Grant: クライアント自身が資源へのアクセス権を取得するフロー。ユーザーの介在がないサーバ間通信などに適用されます。
Access Token: 保護されたリソースへアクセスする際に用いる短期的なトークン。通常はBearerトークンとして送信します。
Refresh Token: アクセストークンの有効期限が切れた際に新しいアクセストークンを取得するための長寿命トークン。
Token Endpoint: 認可サーバがアクセストークンを発行するための API エンドポイント。
Authorization Endpoint: 認可サーバに対して認可を開始するためのエンドポイント。
Resource Server: 保護されたリソース（APIなど）を提供するサーバ。
Authorization Server: 認可を管理し、アクセストークンを発行するサーバ。
Redirect URI: 認可完了後に結果を受け取るクライアントのコールバックURL。
Client: OAuth 2.0 の利用を申し込むアプリケーション。クライアントIDと秘密情報を持つことがあります。
Resource Owner: リソースを所有する者、通常はサービスの利用者（ユーザー）です。
Scope: クライアントがアクセスできる資源の範囲を示す権限の集合。
State: CSRF 攻撃を防ぐため、リクエストと同時に送る乱数値。
Client ID: クライアントを一意に識別する識別子。
Client Secret: クライアントの秘密情報。安全に保管し、サーバ間でのみ共有します。
Public Client: 秘密情報を安全に保持できないクライアント。
Confidential Client: 秘密情報を安全に保持できるクライアント。
Bearer Token: アクセストークンの代表的なトークンタイプ。HTTPの Authorization ヘッダで渡します。
JWT (JSON Web Token): 署名付きのトークン表現。JSON 形式のデータを安全に伝えるために用いられます。
Code Verifier: PKCE で使用する、ランダムに生成する文字列。
Code Challenge: PKCE で Code Verifier をハッシュ化した値。認可コードと結びつけて検証します。
Code Challenge Method: PKCE でのハッシュ方法を指定。例: S256（SHA-256）。
PKCE (Proof Key for Code Exchange): 認可コードフローのセキュリティを強化する拡張。コード盗聴を防ぎます。
OpenID Connect (OIDC): OAuth 2.0 の上にアイデンティティ情報を追加する拡張。ログイン情報の取得が可能になります。
Error Codes (OAuth 2.0): 問題発生時のエラーコード。例: invalid_request、unauthorized_client、access_denied、unsupported_response_type、invalid_scope、server_error、temporarily_unavailable。
Authorization Header: トークンを渡す際の一般的な HTTP ヘッダ。例: Authorization: Bearer 。
Redirect URI Validation: 登録済みのリダイレクト URI と実際のリクエスト URI の一致を検証するセキュリティ対策。
Consent: ユーザーがアプリに対してどの範囲の権限を与えるかを示す同意プロセス。
Token Introspection: アクセストークンの有効性や属性を認可サーバに問い合わせる機能。
Token Revocation: 不要になったトークンを取り消す機能。ユーザーのセキュリティを高めます。
Issuer (iss) and Audience (aud) (JWT claims): JWT の発行者を示す iss と、対象となる受け手を示す aud などのクレーム（トークンの信頼性を判断する要素）。
Response Type: 認可サーバが返す情報の形式を指定するパラメータ。例: code、token。
Grant Type: アクセストークンを取得する方法の種類。例: authorization_code、implicit、password、client_credentials。
Authorization Code: Authorization Endpoint からクライアントへ返される一時コード。これを用いてアクセストークンを取得します。
Access Token Scope: アクセストークンに付与される権限の範囲。スコープが広いほど利用できる資源が増えます。
Token Endpoint Authentication Methods: クライアント認証の方法。例: client_secret_basic、client_secret_post、private_key_jwt、none。