0

サービスの ID は、データベースに保存されているトークンに基づいています。これは、ユーザー名とパスワードを使用してログインすることにより、クライアントによって取得されます。

リソースが要求されるたびに、トークンを検証し、ユーザーがそのリソースへのアクセスを承認されているかどうかを判断する予定です。

当社のサービスは個別に展開されており、認証サーバーには HTTP 経由でアクセスできます。

リクエストを承認する際のベスト プラクティス/一般的な方法は何ですか?

要求された権限と役割でトークンを送信しています

認可サーバーへのトークン検証リクエストで、ユーザーのロールとリクエストされたパーミッションを指定してトークンを渡すことを考えていました。

{
 token: 'xyz',
 role: 'ROLE_ADMIN',
 permission: 'SAVE_USER'
}

成功の場合は 200、無効なトークンの場合は 401、パーミッションの使用が許可されていない場合は 403 で応答します。

認可リクエストでトークンのみを送信する

念頭に置いている別のアプローチは、トークン検証リクエストのトークン内のトークンのみを認可サーバーに送信することです。

{
 token: 'xyz'
}

そして、ユーザーが持っているすべての権限と役割で応答します。

{
 roles: ['ROLE_ADMIN', 'ROLE_USER'],
 permissions: ['SAVE_USER', 'DELETE_USER', 'SHOW_USER']
}

これらのうち、より望ましいのはどれですか? または、私が検討できる他の/パターンのアプローチはありますか?

4

1 に答える 1

0

あなたが「サービス」について話しているとき、それはあなたのサービスがそれを要求する前に何ができるかを知ることを好む可能性が高いことを意味します.

たとえば、リクエストが到着する前にユーザーがクリックできるボタンを強調表示したい場合があります。

したがって、2番目のアプローチは問題ないと思います。そして、リクエストがサーバーに渡される間に、一種の最初のアプローチが実行されます。ユーザーが何かを削除したいのですが、十分なアクセス権がないため、403 が返されます。

セキュリティについて言えば、あなたが説明した両方の方法で、十分なチェックがあります。最初のものでは、ユーザーが何らかのアクションを要求すると、実行される前にGETS CHECKEDが実行され、それが実行されるべきです。

于 2017-09-29T17:03:20.360 に答える