Cognito UserPoolsのFederationの使い方と、そのJWTを独自APIサーバーで検証する方法 - Qiita
Cognito Federated Identities と、Cognito User Pools の Federation とは別の機能です。 よくあるユースケースとして、Cognito User Pools のユーザーに対して API Gateway の認証必須 API を呼び出せるようにするというものがあると思いますが、その場合は、Cognito User Pools を Cognito Federated Identities の認証プロバイダとして登録する必要があります。 ですが、今回は API Gateway の API ではなく、独自サーバーの API なので、Federated Identities は不要です。 2018/04/27追記 API Gatewayの機能でAPIのエンドポイントに対して Authorization: COGNITO_USER_POOLS を設定
Lambda トリガーを使用したユーザープールワークフローのカスタマイズ - Amazon Cognito
Lambda 関数を作成してから、ユーザーのサインアップ、確認、およびサインイン (認証) などのユーザープール操作中に Lambda トリガーを使用してこの関数を有効化できます。認証チャレンジの追加、ユーザーの移行、検証メッセージのカスタマイズを行うことができます。 Lambda トリガーは、ユーザーがユーザープールでアクションを開始した後に Amazon Cognito がユーザーに配信するレスポンスをカスタマイズできます。例えば、他の方法では成功するはずのユーザーによるサインインを禁止したり、ID トークンにクレームを追加したりできます。また、お客様の AWS 環境、外部 API、データベース、ID ストアに対してジャストインタイムオペレーションを実行することもできます。例えば、ユーザー移行のトリガーでは、外部アクションと Amazon Cognito の変更を組み合わせることができ
Amazon Cognito ID プール (フェデレーティッド ID) の使用開始方法 - Amazon Cognito
現在、Amazon Cognito の ID プールは古いバージョンの Amazon Cognito コンソールを使用しています。[フェデレーティッドアイデンティティ] を選択して、ID プールコンソールに移動します。 Amazon Cognito ID プールを使用すると、一意のアイデンティティを作成し、ユーザーに許可を割り当てることができます。ID プールには以下を含めることができます。 Amazon Cognito ユーザープール内のユーザー Facebook、Google、Apple、または SAML ID プロバイダーなどの外部 ID プロバイダーを使って認証するユーザー。 独自の既存の認証プロセスによって認証されたユーザー
SAML ID プロバイダーとして AD FS を設定する
Amazon Cognito ユーザープールで Security Assertion Markup Language 2.0 (SAML 2.0) ID プロバイダー (IdP) として Active Directory Federation Services (AD FS) を使用したいと考えています。どのように設定すればよいですか? 簡単な説明 Amazon Cognito ユーザープールでは、AD FS などの SAML IdP を含め、サードパーティー (フェデレーション) を介してサインインすることができます。詳細については、「サードパーティーを介したユーザープールサインインの追加」および「ユーザープールへの SAML ID プロバイダーの追加」をご参照ください。 Amazon Elastic Compute Cloud (Amazon EC2) Windows インスタンスに
Authentication
Authentication AWS Amplify Authentication module provides Authentication APIs and building blocks for developers who want to create user authentication experiences. Amazon Cognito Amazon Cognito User Pools is a full-featured user directory service to handle user registration, authentication, and account recovery. Amazon Cognito Federated Identities on the other hand, is a way to authorize your use
ステップ 3. ユーザープールにソーシャルサインインを追加する (オプション) - Amazon Cognito
アプリユーザーが Facebook、Google、Amazon、Apple などのソーシャル ID プロバイダー (IdP) を介してサインインするようにできます。ユーザーが直接サインインしても、サードパーティーを介してサインインしても、すべてのユーザーにはユーザープールにプロファイルがあります。ソーシャルサインイン ID プロバイダーを通じてサインインを追加しない場合は、この手順を省略してください。 ステップ 1: ソーシャル IdP に登録する Amazon Cognito でソーシャル IdP を作成する前に、アプリケーションをソーシャル IdP に登録して、クライアント ID とクライアントシークレットを取得する必要があります。 Facebook の開発者アカウントを作成します。 Facebook 認証情報を使用してサインインします。 [My Apps] (マイアプリ) メニューか
認可エンドポイント - Amazon Cognito
/oauth2/authorize エンドポイントは、2 つのリダイレクト先をサポートするリダイレクトエンドポイントです。URL に identity_provider または idp_identifier のパラメータを含めると、ユーザーはその ID プロバイダー (IdP) のサインインページにそのままリダイレクトされます。それ以外の場合は、リクエストに含まれるものと同じ URL パラメータを持つ ログインエンドポイント にリダイレクトされます。 認証エンドポイントを使用するには、ユーザープールに以下のユーザープールの詳細に関する情報を提供するパラメータを使用して、ユーザーのブラウザを /oauth2/authorize で呼び出します。 サインインするアプリクライアント。 終了させたいコールバック URL。 ユーザーのアクセストークンでリクエストする OAuth 2.0 スコープ。
AWS Cognitoのエンドポイントを使いこなす - Qiita
OpenID Connectでは、以下の4つのアクセス権限付与フローが定義されています。 Authorization Code Grant Implicit Grant Resource Owner Password Credentials Grant Client Credentials Grant これらは、AWS Cognitoにある以下の5つのエンドポイントを組み合わせて実現します。 認証エンドポイント (/oauth2/authorize) ユーザーをサインインさせます トークンエンドポイント (/oauth2/token) ユーザーのトークンを取得します。 ログインエンドポイント (/login) ユーザーをサインインさせます。ログインページにロードされ、ユーザーにクライアントに設定されている認証オプションを提示します。 ログアウトエンドポイント (/logout) ユーザーを
API Gateway Lambda オーソライザーを使用する - Amazon API Gateway
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 API Gateway Lambda オーソライザーを使用する Lambda オーソライザー (以前のカスタムオーソライザー) は、Lambda 関数を使用して API へのアクセスを制御する API Gateway の機能です。 Lambda オーソライザーは、OAuth や SAML などのベアラートークン認可戦略を使用する、または発信者 ID を判断するためにリクエストパラメータを使用するカスタム認証スキームを実装する場合に便利です。 クライアントが API のメソッドの 1 つにリクエストを送信すると、API Gateway は Lambda オーソライザーを呼び出します。これは発信者 ID を入力として受け取り、IAM ポリシーを出力として返します。 La
Amazon API Gateway の Custom Authorizer を使い、OAuth アクセストークンで API を保護する - Qiita
Amazon API Gateway の Custom Authorizer を使い、OAuth アクセストークンで API を保護するAWSOAuthAPIGatewayAWSLambdaAuthlete 1. Custom Authorizer とは？ 2016 年 2 月 11 日に AWS Compute Blog の「Introducing custom authorizers in Amazon API Gateway」 という記事で、Amazon API Gateway に Custom Authorizer という仕組みが導入されたことがアナウンスされました。 これにより、Amazon API Gateway で構築された API にクライアントアプリケーションが (OAuth や SAML 等の) Bearer トークンを提示してきたとき、そのトークンのバリデーションを外
API Gateway リソースポリシーを使用して API へのアクセスを制御する - Amazon API Gateway
Amazon API Gateway のリソースポリシーは、JSON ポリシードキュメントです。指定されたプリンシパル (通常、IAM ユーザーまたはロール) で API を呼び出せるかどうかにかかわらず、制御する API にアタッチします。API Gateway リソースポリシーを使用すると、API を以下から安全に呼び出すことができます。 指定された AWS アカウントのユーザー 指定されたソース IP アドレス範囲または CIDR ブロック 指定された Virtual Private Cloud (VPC) または VPC エンドポイント (任意のアカウント) API Gateway のすべての API エンドポイントタイプ (プライベート、エッジ最適化、リージョン) のリソースポリシーを使用できます。 プライベート API の場合は、リソースポリシーを VPC エンドポイントポリシ
IAM - Multi-Factor Authentication
AWS multi-factor authentication (MFA) is an AWS Identity and Access Management (IAM) best practice that requires a second authentication factor in addition to user name and password sign-in credentials. You can enable MFA at the AWS account level for root and IAM users you have created in your account. AWS is expanding eligibility for its free MFA security key program. Verify your eligibility and
Amazon Cognito User Poolsを使って、webサイトにユーザ認証基盤を作る - Qiita
概要 AWS Summit 2016 Chicago にてAmazon Cognitoの新機能として発表された「User Pools」を使ってwebサイトにユーザ認証基盤を作ります。User Poolsはサインインやサインアップ、セッション管理など、よくあるユーザ管理機能をマネージドで提供してくれるサービスです。 [New] Amazon Cognito 向け User Pools User Poolsの作成 [新機能] Amazon Cognito に待望のユーザー認証基盤「User Pools」が追加されました！ 作成方法についてはClassmethodさんのブログに詳しく乗ってますので参考にしてください。 JavaScriptからUser Poolsの認証機能を使う時の注意点として、以下のAppsの作成でGenerate client secretのチェックを外してください。Java
Amazon Cognito user pools - Amazon Cognito
Amazon Cognito ユーザープールは、ウェブおよびモバイルアプリケーションの認証と承認のためのユーザーディレクトリです。アプリケーションの観点から見ると、Amazon Cognito ユーザープールは OpenID Connect (OIDC) ID プロバイダー (OIDC) です。ユーザープールには、セキュリティ、ID フェデレーション、アプリ統合、ユーザーエクスペリエンスのカスタマイズなどの機能が何層も追加されます。 例えば、ユーザーのセッションが信頼できるソースからのものであることを確認できます。Amazon Cognito ディレクトリを外部 ID プロバイダーと組み合わせることができます。お好みの AWS SDK を使用して、アプリに最適な API 認証モデルを選択できます。また、Amazon Cognito のデフォルトの動作を変更またはオーバーホールする AWS
【レポート】Backend Engineer’s meetup ~マイクロサービスにおける認証認可基盤~ | DevelopersIO
本記事は、2019年8月21日に行われたmerpay社の主催するイベント、「Backend Engineer’s meetup ~マイクロサービスにおける認証認可基盤~」の参加レポートです。 Backend Engineer’s meetup ~マイクロサービスにおける認証認可基盤~ レポート セッションの概要 メルペイ社の認証基盤チームの担当している 外部向けに提供しているOIDCなどの認可の仕組み 内部のマイクロサービス間通信の認証の仕組み のうち、後者についてのお話を聞いてきました。セッションのスライドはこちらで公開されています。 チームがやっていること 認証基盤チームではユーザーアカウント管理とかログインはやってない 従業員の管理とかはやってない セキュリティについてはセキュリティチームと相談しながらやっている それ以外の認証認可を認証基盤チームがやっている 現状のアーキテクチャ
Mockを使って、Facebookログイン部分のRSpecを書いてみた！! - Clueit Developersブログ
こんにちは、エンジニアの神山です。 最近、テストカバレッジを上げるためRSpecを書きまくっています。ちなみに最初は90%でしたが、苦闘の末95%まで上がりました。結構骨が折れましたね。 その中でも大変だったのがFacebookログイン部分のテストです。外部APIを使っており、そこの部分のテストの書き方が分からなくて悩んでいました。 色々と調べてみるとモックを使うとうまいことテスト出来るよという文献を見つけました。 ということで今回は、外部API部分のテストの問題点、モックとは何か、またそれをどのようにテストに使うのかにフォーカスして記事を書きました。 外部API部分のテストの問題点 今回悩んだのは外部APIを使用している部分のテストをどのように書くかということです。 例えば、「ログインしようとしているユーザーのFacebookのアカウント情報を取得し、すでにDBに登録されていればログイン
JWTを使った今どきのSPAの認証について | HiCustomer Lab - HiCustomer Developer's Blog
TL;DR JWTはCookieを使った認証の代わりに使うのはきつい。 コードを静的にホスティングしているSPAの話。 JWTの有効期間を長くすれば危険で、短くすればUXが犠牲になるというトレードオフがある。 AWS AmplifyはlocalStorageにJWTを保存 悪意のあるThird partyライブラリが混ざっていたらJWTを抜かれる。 yarn.lockが依存している全ライブラリを監査することはつらい。 Auth0ではiFrameを活用してメモリ上にJWTを格納できる Auth0いいね😍 まくら Youtubeが大好きなHiCustomerの小田です。ちょっと遅いですが年明け最初のエントリーです。今年もテックブログをよろしくお願いします😎ちなみに、気分がいいので年明けに観ていたYoutubeのエントリーの中で一番おもしろかった動画を紹介します。世界中で有名な「Auld L
TravisCIからGitHubへのデプロイが401 - Bad credentialsで失敗する問題の対応 - Qiita
以下の手順を踏んだところdeployでエラーが出て失敗する。 travisコマンドのバージョンは1.8.9、使用しているtravisは.comの方である。 予め.travis.ymlがあるリポジトリに移動する travis login travis setup releases pushしてTravisが動く 上記で次のようなエラーが出る。 Preparing deploy /home/travis/.rvm/gems/ruby-2.4.1/gems/octokit-4.6.2/lib/octokit/response/raise_error.rb:16:in `on_complete': GET https://api.github.com/user: 401 - Bad credentials // See: https://developer.github.com/v3 (Octok
JWTでセッション管理してはいけない - Qiita
世の中にはJWT(JOSE/JWS/JWE)でセッション管理をしてはいけないという記事が2017年から山ほどあるのに、なぜかJWTでセッション管理をしようとする人がいる。翻訳記事だったり暗号の説明が長すぎたりして、JWTをセッションに使ってしまうような人の心に刺さってないんじゃないだろうか。 前提 JWTでセッション管理というのは、暗号化したトークンをブラウザのCookieに持たせて、サーバー側ではトークンを復号化してユーザー判定などのセッション管理を行うことである。サーバー側で[sessionId: userId]のペアを管理する必要がないのでステートレスに扱えてスケールしやすいというメリットがある。 問題 すごく便利な図があったのでまずこれを読んで欲しい。セッション方式の策定/設計をする職位の人ならすんなり読めると思う。 co3k.orgより引用 1 左から４番目Local Stora
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://github.com/jamiehannaford/what-happens-when-k8s/tree/master/ja-jp
