Application Load Balancer を使用してユーザーを認証する - Elastic Load Balancing
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 Application Load Balancer を使用してユーザーを認証する Application Load Balancer を設定して、ユーザーがアプリケーションにアクセスしたときに安全に認証できます。これにより、アプリケーションがビジネスロジックに集中できるように、ユーザーを認証する作業をロードバランサーに任せることができます。 次にユースケースがサポートされています。 OpenID Connect (OIDC) に準拠する ID プロバイダー (IdP) を使用してユーザーを認証します。 Amazon や Google IdPsなどのソーシャル を通じて FaceBook、Amazon Cognito でサポートされているユーザープールを通じてユーザー
Amazon Cognito ユーザープールエンドポイントへのアクセスパターンを考える - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
こんにちは ! AWS Community Hero の山口です。みなさん、Amazon Cognito は使われていますか ? ウェブアプリケーションまたはモバイルアプリケーションを開発する際、ユーザーごとにデータへのアクセス制御や権限制御など、認証と認可が機能として求められることがあります。現在では、認証・認可が求められないケースの方が少ないと言っても過言ではないと思います。 そのような時に、Amazon Cognito ユーザープール (以降、Cognito ユーザープール) を利用することで素早く簡単にユーザーのサインアップ / サインイン (認証) を提供することや、認証された結果にもとづくアクセス制御を実装することができます。また、Cognito ユーザープールは、OpenID Connect、OAuth 2.0、SMAL2.0 などの標準化された認証・認可プロトコルをサポート
EC2とALBでコンテンツを配信している環境にCognitoで認証を追加してみました | DevelopersIO
こんにちは、コンサル部＠大阪オフィスのTodaです。 EC2とALBを使ってコンテンツを配信している中で、全てのページまたは一部のページを許可したユーザのみ掲載したいという要望を受けた場合、ログインのシステムを作りコンテンツをログイン済みのみ参照できるようにする方法があると考えます。 今回はシステムを作らず設定のみでEC2とALBに認証を実装してみます。 ユーザの管理はcognitoを利用しておこないます。 変更予定のイメージ図 制限事項 今回ALBとCognitoを連携して認証を実装いたします。 実装時に利用できるサインアップ・サインイン画面は英語のみの表示になりデザインはロゴ画像など変更箇所が制限されます。 前提条件 ALBとEC2によりWebサイトが表示される状態から対応いたします。 コンテンツの配信はHTTPS通信にておこなっている状態から対応いたします。 Cognitoの準備につ
PowerPoint プレゼンテーション
© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. S U M M I T AWSを活用した ユーザー認証実装パターン解説 堀場 隆文 コンサルタント アマゾン ウェブ サービス ジャパン株式会社 プロフェッショナルサービス本部 B 2 - 0 6 © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. S U M M I T 自己紹介 名前： 堀場 隆文（ほりば たかふみ) 所属： プロフェッショナルサービス本部 職種： コンサルタント 業務： 技術的な課題を中心にお客様をご支援 ・マスマイグレーションに向けたクラウド標準化 ・サーバレスアプリ構築 好きなAWSサービス： AWS Lambda © 20
PHP + Google Authenticator（TOTP）２段階認証の実装方法
2019年7月、あるスマートフォン決済サービスが不正利用され多くの利用者の方が被害に遭われました。その決済サービスには、２段階認証やそれに準ずるセキュリティ対策を怠ったとして大きな批判が集まりました。高い安全性が求められるサービスでは、パスワード認証だけでは安全を確保することが難しくなっています。そこで今回は、PHP と Google Authenticator を使った２段階認証の実装方法をまとめてみました。 Google Authenticator（TOTP）２段階認証の仕組み Google Authenticator は、RFC6238 Time-Based One-Time Password Algorithm（よく「TOTP」と略されます）に基づいて時間ベースのワンタイムパスワードを生成します。クライアント側で利用する TOTP生成アプリは Google Authenticato
二段階認証JAVA実現（TOTP） - Qiita
1.はじめに ある社内システムを外部へ公開により、セキュリティ対策を強化するため、ログインの二段階認証を実現したい。ITエンジニアの私として、二段階認証の実現方法を検討します。 2.二段階認証の使用流れ 各サイトに二段階認証機能を使うと、QRコードをスキャンしてから、認証アプリをアカウントに登録するよう求めるメッセージが表示 色々認証アプリがあり、例えば、Google Authenticator、Authy、Duo Mobile、1Passwordなど(時間ベースのワンタイムパスワード（TOTP）認証アプリ) QRコードをスキャンしたら、認証アプリにより、30秒ごとにパスワードを生成される 普通のログインパスワード以外、該当パスワードは二段階認証コードとして使う 3.TOTP 時間によってワンタイムパスワードが計算される仕組みから「Time-based One-Time Password」
二段階認証を実装するまでに調べたこと - Qiita
二段階認証を実装するにあたり、自分が調べたことをまとめました。 何か間違ったことがあれば、コメントいただけると幸いです！ 二段階認証?二要素認証 英語では、二段階認証を「Two-Factor-Auth」と訳しますが、日本語では「二段階認証」と「二要素認証」は明確に異なります。 二段階認証の説明をする前に、認証の3要素について説明する必要があります。 認証の三要素 私たちが普段Webサービスを利用する際に、アカウントが自分のものか、認証を行います。その代表的な手段として「メールアドレス」と「パスワード」が一般的です。ですが、一個人を特定する方法として、他にも種類があります。それらを3つに分類したものを「認証の3要素」と呼んだりします。以下のように分けられます。 ユーザが知っていること（知識情報） ID・パスワード 秘密の質問 ユーザが持っているもの（所持情報） 電話番号 キャッシュカード ワ
OAuth2.0の流れをまとめてみる
※この記事は別アカウント(hyiromori)から引っ越しました はじめに 最近、個人的に認証認可周りを学習していて、その過程でOAuth2.0について学習している内容をまとめた記事です。 世の中には既にOAuth2.0に関する優れた書籍やブログ記事が沢山ありますが、自分が学習する過程で色々なものを読むことでより理解が深まったと思うので、自分も学習したものをアウトプットすることで同じように学習している人の理解の助けになればと思い書きました。 まだ私も学習中なので、もし間違ったところなどあればコメント頂けるとありがたいです。 注意点 この記事内ではOAuth2.0で定義されているフロー の1つ、認可コードによる付与（Authorization Code Grant）についてまとめています。 たくさんの仕様をいきなり網羅的にまとめるのは難しいので、1つに絞って今回はまとめています。 OAuth
Cloud Identity-Aware Proxy におけるアクセス制御の仕組み | Google Cloud 公式ブログ
Google Cloud Next '17 において、私たち Google は Cloud Identity-Aware Proxy（Cloud IAP）のベータ版を発表しました。Cloud IAP を使用すると、Google Cloud Platform（GCP）上のウェブ アプリケーションへのアクセスを制御できます。 Cloud IAP に関する前回の投稿では、Cloud IAP の概要と、Cloud IAP によるアクセス制御が、従来の LAN や VPN などにおける境界ベースのアクセス制御よりも簡単で安全なことを説明しました。今回はさらに踏み込んで、Cloud IAP の仕組みと、その開発過程で私たちが行った技術上の決定について解説します。 Cloud IAP の仕組み リクエストが App Engine か Cloud Load Balancing HTTP(S) に送信される
JSON Web Token（JWT）のClaimについて · なるはやで いい感じの 動作確認
REST APIなどを開発すると、避けては通れないものに認証があります。 最近はOAuth2 Providerを実装することが多いのですが、発行するアクセストークンにJSON Web Token（JWT）を利用しています。 JWTは名前の通り、RFC7519によって定義されたスキーマを持つJSONです。 JSONの各キーとして、RFCで定義されている標準的なキーと値のペア（Claim）を取ることにより、標準的な取り扱いが可能になります。 本記事では、JWTのClaimについて、OAuth2 Providerでのアクセストークンを発行する立場から、備忘録的にまとめたいと思います。 なお、JWTにはJOSE Headerのような、Claimとは別の仕様も含まれていますが、本記事ではClaimのみを対象とします。 アクセストークンとしてJWTを利用することの利点 JWTは単なるJSONのため、ア
署名付きヘッダーによるアプリの保護 | Identity-Aware Proxy | Google Cloud
フィードバックを送信 署名付きヘッダーによるアプリの保護 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 このページでは、署名付きの IAP ヘッダーを使用してアプリを保護する方法について説明します。Identity-Aware Proxy（IAP）を構成すると、JSON Web Token（JWT）によってアプリに対するリクエストが承認されます。アプリは次のようなリスクから保護されます。 IAP が誤って無効化される ファイアウォールの設定が誤っている プロジェクト内からのアクセス アプリを適切に保護するには、すべてのアプリの種類に対して署名付きヘッダーを使用する必要があります。 また、App Engine スタンダード環境アプリを使用している場合は、Users API を使用できます。 Compute Engine と GKE のヘルスチェックには J
GKEにデプロイしたアプリケーションをIAP(Identity-Aware Proxy)で保護するまで - Qiita
はじめに 業務都合で、GKEにデプロイしたアプリケーションを、 Identity-Aware Proxy で保護（認証・認可）する方法を調べたので実際の環境構築方法をメモしてみました。 Identity-Aware Proxyとは ざっくりいうと、Googleアカウントによる認証と、ユーザに対する認可を一度にやってくれる機能です。 例えば許可のないユーザには、以下のような画面を出してアクセスをブロックしてくれます。 ただ本来自分たちがやりたいことをどこまで実現できるのかは調査中でして、それは次の記事で調べていこうと思います。 まずは環境構築までを書いてみました。 IAPによりアプリケーションの認証・認可を行う場合の前提条件 GKEに対してIAPを適用するための手順が こちら になります。 まず確認すべきはここに書かれている前提条件。 課金が有効になっている Google Cloud Con
外部 ID の有効化 | Identity-Aware Proxy | Google Cloud
フィードバックを送信 外部 ID の有効化 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 この記事では、外部 ID を使用するように Identity-Aware Proxy（IAP）を構成する方法について説明します。IAP と Identity Platform を組み合わせることで、Google アカウントだけでなく、OAuth、SAML、OIDC など、さまざまな ID プロバイダを使用してユーザーを認証できます。 Identity Platform の有効化と構成 IAP は Identity Platform を使用して外部 ID の認証を行います。このプラットフォームを有効にする方法については、Identity Platform のクイックスタートをご覧ください。 複数のテナントを使用する場合は、マルチテナンシーのスタートガイドの手順にも従う
マイクロサービス時代のセッション管理 - Retty Tech Blog
この記事はRetty Advent Calendar 2019 21日目の記事です。エンジニアの 神@pikatenor がお送りします。11日目の記事に書かれた「弊社エンジニアの神（注・人名であり実名です）」とは私のことです。 qiita.com さて世はまさにマイクロサービス大航海時代、大規模化した組織・肥大化したコードベースのメンテナンスを継続的に行っていくべく、アプリケーションを機能別に分割する同手法が注目を集めていることは皆さんもご存知でしょう。 マイクロサービスアーキテクチャ特有の設計課題はいくつかありますが、今回は認証情報のような、サービス間でグローバルに共有されるセッション情報の管理のパターンについて調べたことをまとめてみたいと思います。 背景 HTTP は本質的にステートレスなプロトコルですが、実際の Web サービス上では複数リクエストをまたがって状態を保持するために、
「私はロボットではありません」はワンクリックでなぜ人間を判別できる？ 仕組みとその限界を聞いてきた
2021.02.16 「私はロボットではありません」はワンクリックでなぜ人間を判別できる？ 仕組みとその限界を聞いてきた WebサイトにIDとパスワードを入力するとき、ときどき「私はロボットではありません」にチェックを求められることがあります。 僕はロボットではないので、当然チェックを入れて認証を進めるわけですが……。でもちょっと待ってください。なぜクリックひとつで、人間かロボットかを判断できるんでしょう。 これはきっと、人間ではないなんらかの不正アクセスを防ぐ仕組みのはず。でもチェックを入れるくらい、プログラムを作ってなんやかんやすれば、シュッとできるのでは？ 「私はロボットではありません」は、どんな仕組みで人間とロボットを判別しているのか。もっといい方法はないのか。これまでの歴史的経緯も含め、情報セキュリティ大学院大学の大久保隆夫教授に聞きました。 気づかないうちに「人間かロボットか」
Sign-up form best practices | Articles | web.dev
Sign-up form best practices Stay organized with collections Save and categorize content based on your preferences. Help your users sign up, log in and manage their account details with a minimum of fuss. If users ever need to log in to your site, then good sign-up form design is critical. This is especially true for people on poor connections, on mobile, in a hurry, or under stress. Poorly designe
ちょっとでもセキュリティに自信がないなら、 Firebase Authentication を検討しよう
note のやらかしのあのへんについて。 認証自作、 Rails 、 Devise - Diary パーフェクト Rails 著者が解説する devise の現代的なユーザー認証のモデル構成について - joker1007’s diary 認証サーバーの実装は本質的に難しいです。セキュリティが絡むものは「簡単な実装」などなく、プロアマ個人法人問わず、個人情報を守るという点で、同じ水準を要求されます。悪意あるハッカーは常にカモを探していて、もし認証が破られた場合、自分だけではなく大多数に迷惑が掛かります。初心者だから免責されるといったこともありません。全員が同じ土俵に立たされています。 とはいえ、認証基盤を作らないといろんなサービスが成立しません。そういうときにどうするか。 Firebase Authentication で、タイトルの件なんですが、 Firebase Authenticat
Nuxt.js+Firebaseの認証・認可を実装した雛形プロジェクトを公開しました - Qiita
この記事について NuxtとFirebaseを使って、これまでいくつかサービス開発をしていますが、認証/認可の実装はどのサービスでも毎回同じようなコードを書いている気がします。 サービスとしてのコア部分ではないですが、センシティブな部分なのでしっかりと調べながら実装すると結構大変ですよね（毎回時間がかかってしまいます）。 ここ最近のサービスはNuxt +Firebaseで開発することが多く、認証 / 認可のコードベースのTipsが貯まってきたので公開したら需要あったりするのかな？ サンプルになりそうなプロジェクト見当たらないし、コアな部分ではないのであまり楽しくないし...。 雛形のプロジェクトとして需要あれば公開します👍 — フジワラユウタ | SlideLive▶️ (@Fujiyama_Yuta) June 7, 2020 自分だけではなく、いろんな人が同じような課題感を感じている
一番分かりやすい OpenID Connect の説明 - Qiita
はじめに 過去三年間、技術者ではない方々に OpenID Connect（オープンアイディー・コネクト）の説明を繰り返してきました※1。 その結果、OpenID Connect をかなり分かりやすく説明することができるようになりました。この記事では、その説明手順をご紹介します。 ※1：Authlete 社の創業者として資金調達のため投資家巡りをしていました（TechCrunch Japan：『APIエコノミー立ち上がりのカギ、OAuth技術のAUTHLETEが500 Startups Japanらから1.4億円を調達』）。 2017 年 10 月 23 日：『OpenID Connect 全フロー解説』という記事も公開したので、そちらもご参照ください。 説明手順 （１）「こんにちは！ 鈴木一朗です！」 （２）「え！？ 本当ですか？ 証明してください。」 （３）「はい！ これが私の名刺です！
面倒なログイン機能の実装はFirebase Authenticationに丸投げしよう
突然ですがこれを読んでいる皆さんはログイン機能を作ったことはありますでしょうか？筆者はFirebase Authenticationに触れるまで、ログイン機能というものを作ったことがありませんでした。何となく、ログイン機能を作るのは難しいという認識を皆さんも持っているのではないでしょうか。 ログイン機能とは、「ユーザの認証」と「システムにログインできること」という認可をおこなうことの組み合わせです。 認証と認可の違い 認証はユーザーが誰かを確認することです。認可は確認したユーザーがリソースに対するアクセス権限を持っているかを確認し、権限を持っている場合はリソースへの読み書きを許可します。 近年はOAuthやOpenID等の認証方法が登場し、それぞれの認証方法に対応したアプリケーションコードを毎回書くのは大変です。そこに登場したのがFirebase Authenticationです。Fire
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
