1

そのため、私が構築しているこのAPIのOAuth2を可能な限り厳密に実装しようと遊んでいます。私はaccess_tokenを生成する必要がある時点にいますが、これを行うための最良の方法を見つけようとしています。API呼び出しごとにデータベースが検索されないようにするために、人々がレヴナント情報とaccess_token（有効期限、クライアントIDなど）を暗号化している場所を読みました。

私はそれについて考え、考えました。access_tokenを生成するその方法は、アクセスの取り消しをどのように処理しますか？つまり、OAuthを使用する利点の1つは、データベースを検索せずに暗号化されたデータを使用している場合に、アプリケーションのデータへのアクセスを取り消すことができることです。アプリケーションを取り消すと、引き続きアクセスできます。少なくともそのaccess_tokenが期限切れになるまで私のデータに。

リレーショナルデータベースでのルックアップを防ぐためのより良い方法は、access_tokenをキー/値データベース（redisなど）にも保存することです。これは少し高速になるためです。このようにして、誰かがアプリケーションへのアクセスを取り消すと、リレーショナルデータベースとキー/値データの両方のレコードを削除できます。

何かが足りませんか？暗号化されたデータをaccess_tokenに使用し、データベースが各API呼び出しを検索しないようにし、いつでもアクセスを取り消すことができるようにする方法はありますか？

4

1 に答える 1

1

2 つのアプローチ (データベース内のトークンと自己完結型トークン) の長所と短所を既に知っているので、選択する必要があります。ほとんどのプロバイダーは自己完結型のトークンを使用します。私は、JWS/JWE などの出発点として同じものを提案します。

ただし、単純な自己完結型のトークンの代わりに、少し調整して、2 つの世界の長所を単純なトリックで組み合わせることができると思います (ほとんどのプロバイダーが同じことをしていると思います)。トークンの取り消しが例外的なケースであることを考慮すると (少なくとも通常のトークン操作よりもはるかに少ない頻度で発生する)、取り消されたトークンのリストのみをデータベースに保持できます。. トークンを検証すると、取り消されたトークンのリストでそれを検索できます。見つからない場合は、署名または暗号化されたコンテンツを通常どおり使用できます。この方法でもデータベースは保持されますが、レコードが大幅に少なくなり、ルックアップが高速になります。たとえば、キー/値とリレーショナル データベースの両方を使用する代わりに、キー/値データベースのみを使用できます。API の大量のトラフィックが予想されない場合は、取り消されたトークンのリストをメモリに保持することで、データベース ルックアップ全体を保存することもできます。

于 2013-03-02T18:03:56.860 に答える