3

私は非常に典型的な Web アプリ製品を構築しています。将来的に対応するモバイルアプリが登場する可能性があります。OAuth2を使用して保護されたREST APIを使用して、ゼロから構築しています。OAuth2 が機能しており、さまざまな許可タイプを使用して正常に接続できます。

私が少し混乱しているのは、実際の Web アプリに使用する許可の種類です。これが私が念頭に置いていたことです：

パブリック API アクセス

ユーザーが Web アプリにログインする前に、ユーザー登録やパスワードのリセットなどのためにいくつかの API アクセスが必要です。私はclient_credientialsグラントタイプを使用することを考えていました。アクセス トークンと引き換えに、単純なクライアント ID とシークレットの検証。

ただし、パブリック リクエストごと、またはセッションごとにトークンへのアクセスをリクエストする必要はまったくないようです。Web アプリが常に使用するアクセス トークンを 1 つだけ生成する方が理にかなっているようです。

しかし、これは OAuth が機能するように設計されている方法に反しているようです。たとえば、アクセス トークンは期限切れになります。これを行う正しい方法は何ですか？

プライベート ユーザー API アクセス

次に、ユーザーが Web アプリにログインするには、password付与タイプ (リソース所有者のパスワード資格情報) を使用する予定でした。このアプローチによりuser_id、アクセス トークンを使用して を保存できるため、どのユーザーがログインしているかがわかります。さらに、スコープを使用することで、API 内のアクセスを制限できます。

PHPセッション内にアクセストークンを保存する予定です。PHP セッションがアクティブである限り、Web アプリにログインしたままになります。

これはユーザー ログインの適切な設計ですか?

4

1 に答える 1

4

パブリック API アクセスの場合:

1 つの方法は、トークンをすべてスキップして、API アクセスに基本 HTTP 認証のみを使用することです。このためにクライアント資格情報を受け入れ、クライアント固有のスコープを使用してクライアントができることを制限できます。Github は、すべての API 呼び出しに対してユーザー資格情報を使用するHTTP 基本認証を提供します。

プライベート ユーザー API アクセスの場合:

Authenticationとの間の線を破り始めるので、これは興味深い質問ですAuthorization。OAuth を使用するためAuthorization、ユーザーのログインが難しくなります。たとえば、セッション管理は OAuth2.0 仕様でカバーされていないものです。

ただし、これはとにかく OAuth2.0 の一般的な使用法です。passwordアクセス トークンを取得するには、グラント タイプまたはその他のグラント タイプを使用できます。主な欠点は、パスワードを使用してアプリケーションを信頼する必要があることです (独自のアプリにとっては大したことではありませんが、サードパーティにとってはそれほど重要ではありません)。また、ある場所にログインしているからといって、必ずしも別の場所にログインしているとは限りません (SSO ではなく、「リンクされたアカウント」があるため、セッションは個別に管理されます)。これを回避する 1 つの方法は、常にユーザーを oauth 承認エンドポイントに送信し、ユーザーのセッションが OAuth2.0 プロバイダー側​​でアクティブな場合は、アクセス トークンまたは承認コードを使用してクライアント アプリに再ルーティングすることです。このようにして、セッションが OAuth2.0 プロバイダーでアクティブな場合、クライアントはすぐにログインできます。

于 2013-09-04T17:07:49.637 に答える