タグ付けされた質問 「oauth2」

oAuth2を使用するAPIと、このAPIをバックエンドとして使用する独自のモバイルアプリがあります。ユーザーは複数のデバイス（iPhone、iPad、Androidタブレット、Androidフォンなど）を介して同時にログオンできるため、各接続を区別するAPIが必要です。個別のアクセストークンを介してこれを実行したいです。各クライアントは個別のアクセストークンを取得します。 問題は、現在使用している実装（spring-security-oauth2）がclient_id、ユーザー名、スコープに基づいて一意のキーを生成することです。したがって、基本的に、アクセストークンを取得すると、すべてのクライアントは同じユーザーに対して同じアクセストークンを取得します。これは、DefaultAuthenticationKeyGeneratorを使用して行われます。 認証キージェネレーターを無視して、クライアントからのリクエストごとに新しいアクセストークンを作成するだけで安全ですか？

13 spring  oauth2 

私は現在、自家製の承認と認証システムを使用して、100万人近くのユーザーがいる15歳のレガシーモノリシックWebアプリケーションを持っています。ハッシュアルゴリズムなど）。 今後12〜18か月間、主にUIに重点を置いてアプリケーションのオーバーホールを行いますが、基盤となるパーツもゆっくりとアップグレードします（Spring、Spring Securityなどへのアップグレード）。このプロジェクトでは、モジュールごとにUIのアップグレードに取り組むことにしました。各モジュールが完成したら利用可能にする。モノリスを個々のWebアプリに分割する絶好の機会（すべて同じUXデザインを維持）。 これを計画しようとして私が行き詰まっているのは、認証と承認のレベルです。すべてのモジュールにまたがるクロスカッティングソリューションが必要です。これにより、ユーザーがあるWebアプリケーションから別のWebアプリケーションに誘導されたときに、シームレスな移行が実現します。ユーザーは異なるWebアプリケーション上にいることさえわかりません。OAuth2は完璧なソリューションのように聞こえます。 これを統合する方法を理解しようとするのに行き詰まっています。独自のカスタムOAuth2サーバーを構築する必要がありますか？それはひどい考えのように私を襲います。しかし、どうやって私は： すべてのユーザーアカウントと承認プロセスをサードパーティのOAuth2サーバーに移行する アプリケーションの残りの部分と一致するようにルックアンドフィールをカスタマイズします（これがどれほど簡単に/可能性が高いかわかりません） サードパーティのサーバーを介して接続するときに、一般的な「アプリケーションXYZがアカウントへのアクセス許可を求めています...」ポップアップを防止しますか？（例：Google OpenID、Facebookなど）。 私の目標は、ユーザーに現在の状態から新しい状態へのシームレスな移行を提供することですが、Webアプリケーションの外部ですべて認証および承認する個別のWebアプリケーションを作成する機能を提供することです。

10 web-applications  spring  oauth2 

私はOAuth2で頭を悩ませようと何度も読んでいましたが、それでも何か混乱しています。 クライアントがOAuthプロバイダー（Googleなど）を承認し、リソースサーバーがユーザーのプロファイルデータにアクセスできることを理解しています。その後、クライアントはアクセストークンをリソースサーバーに送信し、リソースを返すことができます。 しかし、どのドキュメントでもカバーされていないように見えるのは、クライアントアプリがリソースサーバーにリソースを要求し、それにアクセストークンを渡したときに何が起こるかです。これまでに読んだことはすべて、リソースサーバーが要求されたリソースで応答するだけであると述べています。 しかし、それは巨大な穴のようです。確かにリソースサーバーはアクセストークンを何らかの方法で検証する必要があります。そうしないと、古い要求を偽造して、古い、盗まれた、偽の、またはランダムに生成されたトークンを渡すだけで、それを受け入れるだけです。 これまでに読んだものは不完全だと感じるので、誰でも簡単にOAuth2の説明に従うことを私に向けることができますか？

10 security  oauth2 

ASP.NET Coreを使用して新しいWebサイトを作成するときに、全体像を把握しようとしています。私のウェブサイトのユーザーがFacebookやGoogleなどのソーシャルメディアに登録してログインできるようにしたいと考えています。リソースがWebAPIにリソースを要求するときに登録されると、リソース要求をユーザーごとにパーソナライズできるように、ログインしているユーザーを知る必要があります。私はASP.NET Core Identityを試してみましたが、これは必要な機能の多くを提供しているようです（たとえば、外部プロバイダーへの登録、ログイン、Entity Frameworkを使用したデータベースへのこれらの詳細の格納など）。私が本当に望んでいるよりも少し魔法-多くのチュートリアルは、例えばFacebookと話すためにバックグラウンドでどのように機能するかを説明せずにそれを機能させるためのステップをリストしています。 フロントエンドでは、Aureliaを使用したいと考えています。IdentityServerを使用する多数のチュートリアルに気づきました。OpenIDConnectの実装であると理解しています。 IdentityServerに関するビデオを見てきた... IdentityServerでASP.NET Core Identityを使用できることを理解しています。私が得られないのは、それがASP.NET Core Identityを実装するだけでは役に立たないかどうかです。（つまり、Aurelia、ASP.NET Core Identityを統合するためのチュートリアルを見つけることができないようです...）一般的に、ASP.NET Core Identityを使用するだけでなく、Identity Serverをさらに複雑にする利点は何ですか？

9 asp.net  oauth2 

私は、互いにシンフォニーで機能する3つのコンポーネントを設計しているところです。 BasicAuthすべての呼び出しでHTTPS を必要とするRESTful Webサービスであり、これが実際に私のシステムのすべての重労働を実行します（作業を行います） エンドユーザーのアクションを上記のWebサービスへのAPI呼び出しに変換するWeb UI。したがって、UIはWSによって「サポートされます」 開発者がローカルでインストールして実行できるコマンドラインインターフェイス（CLI）ツール。コマンドをWSへのAPI呼び出しに変換します（したがって、これもWSによって「サポートされています」）。 私が乗り越えようとしている最初のハードルの1つは、認証と承認に関するものです。 WSがLDAP /ディレクトリサービス（ADまたはおそらくApache DSなど）を認証レルムとして使用しているとしましょう。つまり、API呼び出しがネットワーク経由で（たとえば、あるHTTPS GETリソースの）BasicAuth受信されると、資格情報が要求から抽出され、LDAPサービスに転送されて、これが有効なユーザーであるかどうかが判断されます。認証されている場合、特定のユーザーが HTTPSリクエストで試行していることを実行できるかどうかを判断するために、別の認証レルム（おそらくデータベース）が使用されているとしましょう。ここまでは順調ですね。 CLIツールの場合、ユーザーはコマンドを実行する前に認証を受ける必要があります。したがって、単一のユーザーは常に同じCLIインスタンスを操作するだけなので、このモデルは問題なく機能します。 Webアプリケーション（UI）をWSと統合しようとすると、問題が発生します。なぜなら、多くの人が同時にアプリにログオンする可能性があり、すべて異なるアクセス許可で、許可されている基本的なAPI呼び出しを指示するためです。 私の知る限り、それを見て、それが見えます私はここが、4つのオプションを持っているように： キャッシュされた資格情報：アプリにログインした後、資格情報が何らかの形であり、どこかで（アプリはそれらへのアクセスを持っているように）キャッシュされた、とアプリが認可ポリシー自体の任意の種類を強制しません。ユーザーが内部でAPI呼び出しを生成することをしようとすると、資格情報がキャッシュから検索され、API呼び出しで転送されます。WSが承認されていないと判断した場合、WSはエラーを返します。 サービスレベルアカウント：アプリとWSはどちらも同じ認証/承認レルムを使用しますが、Web UIは、ユーザーがアプリ内で実際に表示および実行できるものに承認を適用するようになりました。基盤となるAPI呼び出しを生成する何かを実行することが許可されている場合、アプリmyapp-admin-userはユーザーに代わって各API呼び出しでサービスアカウントの認証情報（など）を送信します。 OAuthv2：OAuthが何であるか、またはこのシナリオに適用できるかどうかはわかりませんが、どういうわけかここでの解決策になると思います。 トークンサーバー：サービスレベルのアカウントオプションと同様の方法で、CASやKerberos などのトークンサーバーを使用してユーザーを保証します。ここで、ユーザーがアプリに正常にログインすると、トークンサーバーはアプリにセッションUUIDを送り返し、そのUUIDをWSに登録します。アプリがAPI呼び出しを生成するたびに、UUIDをリクエストに付加し、それがWS側で検証されます。 「Cached Credentials」オプションは、セキュリティ分野で優れていて健全なすべてのものの逸脱のように感じられます。資格情報をどこにでもキャッシュするのは間違っていると感じるだけです。 「Token Server」オプションは、SSOタイプのセットアップでは有効のようですが、この特定のケースでは有効ではないため、私には不便に感じられます。また、セッションUUIDの概念と BasicAuth / HTTPSを同時に使用する良い方法はないと思います。 したがって、これは私が何も知らないOAuthv2と、残りの唯一のオプションとして「サービスレベルアカウント（SLA）*」を残します。SLAオプションは問題ないようですが、次のようないくつかの欠点があります。 サービスアカウントには、基本的にWSに対する「神の特権」が必要です。つまり、ユーザーがボタンをクリックしたり、UIで何かを実行したりできるとアプリが判断すると、UIで使用されているサービスアカウントによる無条件のAPI呼び出しに変換されます。これは気分が悪いですよね？ 2つの権限セット（アプリの各ユーザーに設定された権限セット、次にアプリがWSに対して使用するサービスアカウントに設定された権限セット）を維持すると、権限が互いに同期しなくなる可能性があります何とかして だから私は本当にここには良い選択肢がないようです。確かに私はこれに遭遇する最初の開発者になることはできませんが、Googleの神々に尋ねることはここではあまり助けになりませんでした。何か案は？

9 authentication  authorization  oauth2 

私のショップには、認証にOAuthトークンを使用する.NET Web APIがいくつかあります。現在、各Web APIは承認とリソースサーバーの両方です。ユーザーは、同じ資格情報を使用してこれらすべてのAPIに対して認証を行いますが、現時点では、各APIに対して個別に認証する必要があります。 共有認証サーバーの作成に興味があります（http://bitoftech.net/2014/10/27/json-web-token-asp-net-web-api-2-jwt-owin-authorization-server/）、しかし私はクレームの変換に悩まされています。次の例のように、発行されたトークンに（アプリケーションに固有の）カスタムクレームを追加できると便利です。 public override Task GrantResourceOwnerCredentials(OAuthGrantResourceOwnerCredentialsContext context) { /* validate credentials here... */ var identity = new ClaimsIdentity("JWT"); identity.AddClaim(new Claim(ClaimTypes.Name, context.UserName)); identity.AddClaim(new Claim("sub", context.UserName)); identity.AddClaim(new Claim(ClaimTypes.Role, "Manager")); identity.AddClaim(new Claim(ClaimTypes.Role, "Supervisor")); var props = new AuthenticationProperties(new Dictionary<string, string> { { "audience", (context.ClientId == null) ? string.Empty : context.ClientId …

8 asp.net  oauth2