私は、自分が構築した認可システムではなく、コミュニティがサポートする認可システムに切り替えるための調査を行ってきました。ベストプラクティスを活用したコミュニティ主導のシステムを実装するのではなく、車輪の再組み立てというミスを犯しました。しかし、認証ではなく JWT を使用した認可の例は見つかりませんでした。
あらゆる提案を歓迎します。私が調べた限りでは、JWT と OAuth では、クライアントが既存のアカウントを持ち、トークンを受け取るために認証を行う必要があります。ただし、私のアプリケーションには以下の機能が必要です。
- 匿名ユーザーはアクセス トークンを取得し、いくつかのリソースを取得できる必要があります。これらのゲスト クライアントを認識し、それらのセッション データを保存できる必要があります。
- ゲスト ユーザーはログインして、新しいトークンを取得したり、アクセス レベルを更新して制限されたリソースを要求したり、メンバー専用の操作を実行したりできるようになります。
このプロジェクトを Laravel 5.1 と AngularJS で構築するつもりです。あらゆる提案を大歓迎します。これについてはいくつかの指示が本当に必要です。ドキュメントへの簡単なリンクがあれば十分です。
ベストアンサー1
あなたが説明したユースケースは確かに理解できますが、匿名トークンは実際にはセキュリティを強化しないと主張します。これは、完全に匿名のユーザーが最初に身元を明かすことなく匿名トークンを要求できるためです（そうでなければ匿名ではありません）。したがって、このトークンしなければならないアプリケーションのすべてのユーザー（悪意のあるユーザーを含む）が所有していると想定される
私は Laravel に精通していませんが、この種の機能を実現するための一般的なアプローチは次のようになります。
アプローチ
- ログイン前にユーザー情報を収集できるセッション ライブラリを見つけます (ほとんどのセッション ライブラリがこれを可能にすると確信しています)
- アプリケーションにアクセスするすべてのユーザーに対してセッションを作成します (これにより、ユーザーのプロファイルを作成したり、有用な情報を保存したりすることができます)。
authenticatedエンドポイントとエンドポイントの間に境界を作成しanonymous、ユーザーセッションに存在する有効なアクセストークンを使用して、データを取得/送信します。authenticated- ユーザーが「ログイン」すると、選択した認証プロバイダーを使用して OAuth2.0/OIDC フローを実行し、最終的にトークンを取得できます。
- トークンをユーザーのセッションに保存し（実質的にアクセスを「アップグレード」する）、次に
authenticatedエンドポイントにアクセスしようとしたときにアクセスできるようにします。
一般的な注意事項
- セッション データをアプリケーションのインスタンス間で共有できるように、セッション データには永続的なストア (通常は Redis などを使用します) を使用してください。