タグ付けされた質問 「restful-authentication」

RESTful認証とは何を意味し、どのように機能しますか？Googleで適切な概要を見つけることができません。私の唯一の理解は、URLでセッションキー（メモ）を渡すことですが、これはひどく間違っている可能性があります。

745 rest  authentication  restful-authentication  rest-security 

RESTful APIでのセッションの使用は本当にRESTfulnessに違反していますか？私は多くの意見がどちらの方向にも進んでいるのを見てきましたが、セッションがRESTなしであるとは思いません。私の視点から： 認証はRESTfulnessで禁止されていません（そうでなければRESTfulサービスではほとんど使用されません） 認証は、リクエストで認証トークンを送信することで行われ、通常はヘッダー この認証トークンは何らかの方法で取得する必要があり、取り消すことができます。その場合、更新する必要があります 認証トークンはサーバーによって検証される必要があります（そうでなければ、認証ではありません） では、セッションはこれにどのように違反しますか？ クライアント側、セッションはcookieを使用して実現されます Cookieは単なる追加のHTTPヘッダーです セッションCookieはいつでも取得して取り消すことができます セッションCookieは、必要に応じて無限の寿命を持つことができます セッションID（認証トークン）はサーバー側で検証されます そのため、クライアントにとって、セッションCookieは、他の独自のヘッダーのCookie代わりにヘッダーを使用することを除いて、他のHTTPヘッダーベースの認証メカニズムとまったく同じAuthorizationです。サーバー側のCookie値にセッションがアタッチされていない場合、なぜ違いが生じるのでしょうか？サーバーが RESTfulに動作する限り、サーバー側の実装はクライアントに関係する必要はありません。そのため、Cookie自体はAPIをRESTlessにすべきではなく、セッションは単にクライアントへのCookieです。 私の仮定は間違っていますか？セッションCookieをRESTレスにするものは何ですか？

491 session  rest  cookies  restful-authentication 

ユーザーだけでなく他のWebサービスやアプリケーションからもアクセスする必要があるRESTful Webサービスを設計しています。すべての着信要求は認証される必要があります。すべての通信はHTTPSを介して行われます。ユーザー認証は、サービスが提供する/ sessionリソースに（SSL接続を介して）ユーザー名とパスワードをPOSTすることで取得した認証トークンに基づいて機能します。 Webサービスクライアントの場合、クライアントサービスの背後にエンドユーザーは存在しません。要求は、スケジュールされたタスク、イベント、またはその他のコンピューター操作によって開始されます。接続サービスのリストは事前にわかっています（明らかに、私は推測します）。他の（ウェブ）サービスからのこれらのリクエストをどのように認証すればよいですか？認証プロセスは、これらのサービスに実装するためにできるだけ簡単にしたいが、セキュリティを犠牲にしてはいけない。このようなシナリオの標準およびベストプラクティスは何ですか？ 私が考えることができる（または私に提案された）オプション： クライアントサービスに「偽の」ユーザー名とパスワードの使用を依頼し、ユーザーと同じ方法でそれらを認証します。私はこのオプションが好きではありません-それはちょうど気分が悪いだけです。 クライアントサービスに永続的なアプリケーションIDを割り当てます。アプリケーションキーも割り当てる可能性があります。私が理解している限り、これはユーザー名とパスワードを持つことと同じです。このIDとキーを使用して、各要求を認証するか、認証トークンを作成して、それ以降の要求を認証できます。どちらにしても、このオプションは好きではありません。アプリケーションIDとキーを入手できる人はだれでもクライアントになりすますことができるからです。 前のオプションにIPアドレスチェックを追加できました。これにより、偽のリクエストを実行することが難しくなります。 クライアント証明書。独自の認証局をセットアップし、ルート証明書を作成し、クライアントサービスのクライアント証明書を作成します。ただし、2つの問題が頭に浮かびます。a）ユーザーが証明書なしで認証できるようにするにはどうすればよいですか。b）クライアントサービスの観点からこのシナリオを実装するのはどのくらい複雑ですか。 何か他のもの-そこに他の解決策があるに違いない？ 私のサービスはJavaで実行されますが、具体的なフレームワークについての情報は意図的に省略しました。これは、実装の詳細ではなく、基本原則に関心があるためです-これに対する最善の解決策は基礎となるフレームワークに関係なく実装することが可能です。ただし、私はこのテーマに少し慣れていないため、実際の実装に関する具体的なヒントや例（有用なサードパーティのライブラリ、記事など）も高く評価されます。

117 web-services  authentication  rest  restful-authentication  client-certificates 

現在、開発環境用にHTTP-Basicで保護されたREST-APIを開発しています。実際の認証はトークンを介して行われるので、2つの認証ヘッダーを送信する方法を理解しようとしています。 私はこれを試しました： curl -i http://dev.myapp.com/api/users \ -H "Authorization: Basic Ym9zY236Ym9zY28=" \ -H "Authorization: Bearer mytoken123" たとえば、IPのHTTP認証を無効にすることもできますが、通常は動的IPを使用してさまざまな環境で作業しているため、これは適切なソリューションではありません。だから私は何かが足りないのですか？

115 rest  curl  basic-authentication  access-token  restful-authentication 

Djangoとdjango-rest-frameworkを使用してRESTful APIを構築しています。 認証メカニズムとして「トークン認証」を選択し、Django-REST-Frameworkのドキュメントに従ってすでに実装しているので、問題は、アプリケーションがトークンを定期的に更新/変更する必要があるかどうか、そうであればどのようにですか？トークンの更新が必要なのはモバイルアプリですか、それともWebアプリで自律的に更新する必要がありますか？ ベストプラクティスは何ですか？ Django REST Frameworkの経験があり、技術的な解決策を提案できる人はいますか？ （最後の質問は優先度が低くなっています）

115 django  rest  restful-authentication  django-rest-framework 

私はexpress + mongooseでnodeを使用しており、restful apiでpassport.jsを使用しようとしています。 認証が成功した後もこの例外が発生し続けます（ブラウザーにコールバックURLが表示されます）。 /Users/naorye/dev/naorye/myproj/node_modules/mongoose/lib/utils.js:419 throw err; ^ Error: passport.initialize() middleware not in use at IncomingMessage.req.login.req.logIn (/Users/naorye/dev/naorye/myproj/node_modules/passport/lib/passport/http/request.js:30:30) at Context.module.exports.delegate.success (/Users/naorye/dev/naorye/myproj/node_modules/passport/lib/passport/middleware/authenticate.js:194:13) at Context.actions.success (/Users/naorye/dev/naorye/myproj/node_modules/passport/lib/passport/context/http/actions.js:21:25) at verified (/Users/naorye/dev/naorye/myproj/node_modules/passport-facebook/node_modules/passport-oauth/lib/passport-oauth/strategies/oauth2.js:133:18) at Promise.module.exports.passport.use.GitHubStrategy.clientID (/Users/naorye/dev/naorye/myproj/config/passport.js:91:24) at Promise.onResolve (/Users/naorye/dev/naorye/myproj/node_modules/mongoose/node_modules/mpromise/lib/promise.js:162:8) at Promise.EventEmitter.emit (events.js:96:17) at Promise.emit (/Users/naorye/dev/naorye/myproj/node_modules/mongoose/node_modules/mpromise/lib/promise.js:79:38) at Promise.fulfill (/Users/naorye/dev/naorye/myproj/node_modules/mongoose/node_modules/mpromise/lib/promise.js:92:20) at /Users/naorye/dev/naorye/myproj/node_modules/mongoose/lib/query.js:1822:13 私は前に置くべきことを読んだことがapp.use(passport.initialize());あり、これは私がやったことです。これがミドルウェアを登録する私のexpress.jsです：app.use(passport.session());app.use(app.router); var express = require('express'), mongoStore …

103 node.js  express  mongoose  restful-authentication  passport.js 

私は、維持しているアプリケーションの1つに対応するRESTful APIの構築に取り組んでいます。現在、より制御されたアクセスとセキュリティを必要とするさまざまなものを組み込むことを検討しています。APIをセキュリティで保護する方法を調査しているときに、どのフォームを使用するかについていくつかの異なる意見を見つけました。HTTP-Authが最適な方法であると言うリソースもあれば、APIキーを好むリソースもあれば、OAuthで誓う他のリソース（私がSOで見つけた質問を含む）もありました。 そしてもちろん、APIキーなどを好む人は、OAuthがユーザーの代わりにアクセス権を取得するアプリケーション向けに設計されていると言っています（私が理解しているように、Facebookアカウントを使用してFacebook以外のサイトにサインインするなど）。特にサインアップしたサイトのリソースに直接アクセスするユーザー（Twitterサーバーにアクセスする公式のTwitterクライアントなど）ではありません。ただし、OAuthの推奨事項は、最も基本的な認証ニーズにも当てはまるようです。 では、私の質問は-すべてがHTTPS経由で行われるとすると、3つの間の実際的な違いは何ですか？いつ他の人よりも考慮すべきですか？

101 security  api  restful-authentication 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 12か月前に閉鎖。 この質問を改善する GraphQLに関するすべての記事で、その素晴らしさがわかりますが、欠点や欠点はありますか？ありがとうございました。

101 rest  restful-authentication  graphql 

この質問にはすでにここに答えがあります： JWTをブラウザのどこに保存しますか？CSRFから保護する方法は？ （5つの答え） 2ヶ月前に閉店しました。 JWTを使用してRESTAPIを保護する目的で、いくつかの資料（このガイドやこの質問など）によると、JWTはlocalStorageまたはCookieのいずれかに保存できます。。私の理解に基づく： ローカルストレージはXSSの対象であり、通常、機密情報を格納することはお勧めしません。 クッキー我々はXSSのリスクを軽減フラグ「のHttpOnly」を適用することができます。ただし、バックエンドのCookieからJWTを読み取る場合は、CSRFの対象になります。 したがって、上記の前提に基づいて、JWTをCookieに保存するのが最善です。サーバーへのすべてのリクエストで、JWTはCookieから読み取られ、ベアラースキームを使用してAuthorizationヘッダーに追加されます。サーバーは、（Cookieから読み取るのではなく）リクエストヘッダーのJWTを確認できます。 私の理解は正しいですか？もしそうなら、上記のアプローチにはセキュリティ上の懸念がありますか？それとも、実際には、そもそもlocalStorageの使用をやめることができますか？

99 security  cookies  local-storage  jwt  restful-authentication 

私はRESTについて読んでいますが、RESTに関する他の多くの質問が他の多くのサイトやブログと同様にあります。私はこの特定の質問が尋ねられるのを見たことがありませんが...何らかの理由で、私はこの概念に心を包むことができません... RESTful APIを構築していて、それを保護したい場合、私が見た方法の1つはセキュリティトークンを使用することです。他のAPIを使用したときは、トークンと共有シークレットがありました...理にかなっています。私が理解していないことは、残りのサービス操作へのリクエストがJavaScript（XHR / Ajax）を介して行われていること、FireBug（またはブラウザの「ソースの表示」）のような単純なもので誰かがそれを盗聴するのを防ぐことです。 APIキーをコピーしてから、キーとシークレットを使用してそのユーザーになりすましますか？

93 restful-authentication 

安全なRESTful Webサービスを実装する必要があります。私はすでにGoogleを使用していくつかの調査を行いましたが、行き詰まっています。 オプション： TLS（HTTPS）+ HTTPベーシック（pc1oad1etter） HTTPダイジェスト two-legged OAuth Cookieベースのアプローチ クライアント証明書（Tom Ritterおよびここ） HMACと制限付きライフタイムを使用した署名付きリクエスト 検討すべきオプションは他にありますか？OAuthの場合、どのバージョンですか？それも重要ですか？これまで読んだことから、署名なしのベアラートークンを使用したOAuth 2.0は安全ではないようです。 RESTベースの認証に関する別の非常に興味深い記事を見つけました。 REST APIを保護する...正しい方法

88 web-services  security  rest  oauth  restful-authentication