API を使用したとき、「401 Unauthorized」という応答を見たことはないでしょうか？
この応答は「認証エラー」であり、ほとんどの API は認証を必要としています。
Ciscoではこの認証の過程で「OAuth」を使用しているAPIがあります。
※読者の方からご指摘いただき、内容を修正いたしました(2021/09/14)
OAuth について、以下順を追って記載します。
1. OAuth とは？
2. OAuth による変化
1. OAuth とは？
OAuth とは、ユーザーが製品/アプリを承認して、別の製品/アプリ内に保存されているリソースにアクセスできるようにする認可のプロセスです。
OAuth のプロセスでは、サードパーティサイトで認証されたユーザーに許可判断されると発行される「アクセストークン」と呼ばれる情報を使用します。
APIを要求する際にこの「アクセストークン」を添付することで、サードパーティサイトがアクセストークンを判定し、リソースにアクセスできる要求であるか検証しています。
ここで検証が成立されなかった場合に、「401 Unauthorized」という応答が返ってきます。
2. OAuth による変化
OAuth が登場する以前は、認証に大きく2点の問題「セキュリティ問題」と「ユーザー制約問題」が存在していました。
セキュリティ問題：
OAuth登場以前の認証プロセスでは、アプリケーションから別サイトのリソースへアクセスしたい場合、別サイトの認証情報をアプリケーション側へ共有する必要がありました。
このプロセスにより、特にパスワードの保存に関連するセキュリティの問題が発生していました。
アプリケーション側では認証情報を独自に暗号化、復号化するなど管理します。
暗号化や複合化に使用できる手法はいくつも存在しており、認証情報を保護するたにどのようなセキュリティ対策を行っているのか知る方法がほとんどありませんでした。
ユーザー制限問題：
同じ認証情報で管理されているアプリケーションからの要求は全て同じアクセス制限で管理されているため、各アプリケーションからの要求に対して異なるアクセス制限を適用する事ができませんでした。
例えば、自社APIを使用しているA社製のアプリAからは取得可能、変更不可としたく、B社制アプリBからは取得可能、変更可能としたい場合、同じ認証情報ではアプリAとアプリBで異なるアクセス制御ができないため「取得可、変更可」「取得可、変更不可」のどちらかに合わせる必要がありました。
OAuth の登場により、上記2点の問題は解決されました。
OAuth のプロセスを使用すると、アプリケーションサイドには、「特定のサービスまたはリソース」に対する要求を許可するためのアクセストークンが発行されます。
このアクセストークンにより「認証情報を公開せず」に、許可判定を行うことが可能になりました。
3. Webex での OAuth認可プロセス
OAuth は4つのロールを定義しています。
※「RFC 6749, 1.1. Roles」参照
RFCを参考に、Webex では各ロールがどのような役割を持っているか確認していきます。
クライアント：
リソースオーナーの許可を得て、保護されたリソースサーバーへ要求を行うアプリケーション。
リソースオーナー：
保護されたリソースサーバーへのアクセスを許可できるエンティティ。
Webex ではユーザーが該当します。
認可サーバー：
リソースオーナーの認証とリソースオーナーからの認可取得が成功した後、アクセストークンをクライアントに発行するサーバー。
Webex では認可取得が成功した際に「認可コード」を認可サーバーで発行します。
クライアントはこの「認可コード」を添付してアクセストークンを発行する認可サーバーへ要求することで、アクセストークンを取得します。
リソースサーバー：
保護されたリソースをホストとしたサーバーで、アクセストークンを検証することでリソース要求を受け入れて応答できるサーバー。
以上のロール間でやり取りを行うことで、Webex API の認可判定を行っています。
Webex の APIでは、どのようなプロセスを行っているか確認してみます。
Webex API の「リソースオーナー」「認可サーバー」「リソースサーバー」は次のものになります。
| ソースオーナー | 認証されたユーザー | |
| 認可サーバー | https://webexapis.com/v1/authorize(リソースオーナーに確認し、認可コードを発行) | |
| https://webexapis.com/v1/access_token(認可コードを判定し、アクセストークンを発行) | ||
| リソースサーバー | https://webexapis.com/リソースパス |
※Webex API の承認サーバーは、アクセストークンと同時にリフレッシュトークンを発行します
Webex API の許可フローは以下の通りです。
リフレッシュトークン：
発行されたアクセストークンは有効期限を持っています。
Webex API ではアクセストークンの有効期限は14日で、アクセストークン発行から14日経過すると同じアクセストークンを使用してリソースサーバーへ要求を出してもエラーとなってしまいます。
そこで登場するのが「リフレッシュトークン」です。
リフレッシュトークンは認可サーバーでアクセストークンを作成した際、アクセストークンの対になって作成されます。
このリフレッシュトークンを使って認可サーバーへアクセストークンの更新を要求することで、アクセストークンが再作成され14日超えても認可が有効になります。
※ただし、この再作成されたアクセストークンも作成してから14日の有効期限であるため、定期的にリフレッシュトークンを使用してアクセストークンの再作成を行う必要があります
リフレッシュトークン自体にも90日の有効期限がありますが、リフレッシュトークンの有効期限は使用すれば更新されます。
参考：
Real world walkthrough of building an OAuth Webex integration
（https://developer.webex.com/blog/real-world-walkthrough-of-building-an-oauth-webex-integration
）
The OAuth 2.0 Authorization Framework
（https://datatracker.ietf.org/doc/html/rfc6749）
Webex の 使い方や TIPS、開発者向けの情報などは、「Webex Connect – Japan」というコミュニティで随時共有されています。Webex をもっと有効活用したいとお考えの方はぜひご参加ください。
Authors