フロントエンドが知って おきたいセキュリティについてフロントエンドが知っておきたいセキュリティについて これからアプリ開発でwebviewで開発したいと言われたフロントエンドエンジニアに読んで欲しい内容です。 アプリからSPAにトークンを渡す方法について記載しています。 関連記事 【OpenID Connect】ログイン情報連携させる時ってど…
セッションが確立されていないFE/BE間でトークンを用いて簡易的なセッションを実現する
ritouです。 何の話か？ このあたりの話です。 FE + BE が存在するID連携 SPAやネイティブアプリといったフロントエンドと、バックエンドサーバーを組み合わせたサービスでID連携を行う際、バックエンドサーバーを起点、終点としたフローを考えられるとセキュアにできますよ、みたいな話を前に書きました。 次に、認可サーバー/リソオースサーバーとのやりとりを Backend Server に任せる パターンです。 リソオース... 前提として、モバイルアプリやSPAとBackend Serverの間にセッションが確立しており、Client は認可リクエストのURLにリダイレクトするだけ、認可レスポンスのパラメータを Backend Server に送るだけです。 このセッションが確立している前提について、ログイン後のID連携などではセッションが確立されているが未ログイン状態のソーシャルロ
SPA に OAuth 2.0 の認可フローを実装してみた - aptpod Tech Blog
aptpod Advent Calendar 2022の20日目を担当します、intdash グループ フロントエンドエンジニアの佐藤です。 早速ですが、弊社では認可制御にOAuth 2.0 を採用しています。 tech.aptpod.co.jp ブラウザのアプリケーションでこの認可制御をする際、Express 等を使ったバックエンドがある場合が多いかと思います。 弊社でもNext.js を用いて、認証を管理するバックエンドサービス (BFF) のある構成をとっています。 このバックエンドがある場合のパターンは、Node.js のクライアント・ライブラリやExmaple も多く、それに従えばおおよその実装はできるのではないでしょうか。(oauth2-proxy が有名でしょうか。) バックエンドがある場合の方がセキュリティレベルは高く、一般的にこちらが採用されることが多いように思えます。
8.x Laravel Sanctum Laravel
イントロダクションIntroduction Laravel Sanctum（サンクタム、聖所）は、SPA(シングルページアプリケーション)、モバイルアプリケーション、およびシンプルなトークンベースのAPIに軽い認証システムを提供します。Sanctumを使用すればアプリケーションの各ユーザーは、自分のアカウントに対して複数のAPIトークンを生成できます。これらのトークンには、そのトークンが実行できるアクションを指定するアビリティ／スコープが付与されることもあります。Laravel Sanctum[https://github.com/laravel/sanctum] provides a featherweight authentication system for SPAs (single page applications), mobile applications, and simpl
Next.jsとAuth0で本管理サイトを作ってみた
Next.jsとAuth0を使って読んだ本を管理するサイトを作ったので使った技術等を紹介します。 github どんなサイトか？ まずは、どんなサイトを作ったのかを紹介します。読んだ本の管理を行うサービスで、主な機能は3つです。 Google Book APIに登録されている本を検索して本棚に保存できる 登録されていないなくてもアプリ内で新しく登録できる。 今まで本棚に登録した本の合計ページ数・本の高さ・本の重さを表示。1ページ当たり0.5g、0.15mmで計算します。 画面遷移 1.トップ画面 アプリのトップ画面。「アカウント作成・ログイン」ボタンを押すことでログイン画面に遷移します。 2.ログイン画面 Auth0を使ったログイン画面。認証方法は2種類あります。 Googleアカウントを使ったログイン メールを使ったログイン 3.ホーム画面 今まで読んだ本を管理する画面。最近読んだ本の表
「挫折しない OAuth / OpenID Connect 入門」のポイント - Authlete
このビデオについて このビデオは、2021 年 10 月 6 日に開催された 「挫折しない OAuth / OpenID Connect 入門」の理解を深める会 のプレゼンテーション録画です。 2021 年 9 月 18 日発売の「Software Design 2021 年 10 月号」では、OAuth/OIDC が特集され、「挫折しない OAuth/OpenID Connect 入門・API を守る認証・認可フローのしくみ」と題し、Authlete 代表の川崎貴彦が寄稿しました。 本プレゼンテーションでは記事のポイントや、理解を深めるために重要なポイントについて、著者の川崎がお話しします。 文字起こし はじめに 目次 記事の第1章、第2章、第3章は、こういう目次になっています。 ここからピックアップして、 こんなことを話してます、というところを、 紹介したいと思います。 自己紹介 Au
OAuth 2.0の代表的な利用パターンを仕様から理解しよう
連載 INDEX 次回 → はじめまして、OpenID Foundation Japan事務局長のNovです。 このたびは、Build InsiderでOAuth 2.0とOpenID Connectに関する記事を書かせていただくことになりました。 今回はOAuth 2.0、次回はOpenID Connectについて、ユースケースごとのフロー（Flow）や関連仕様についてまとめていきます。 OAuth 2.0仕様策定から5年 OAuth 2.0はIETF OAuth WG*1で仕様策定されている標準仕様群である。 最もコアとなるRFC 6749＆RFC 6750はどちらも2012年にRFC化されており、すでに策定から5年以上が経過している。OpenID Foundation Japanの翻訳WGでもこれらは翻訳済みである。 The OAuth 2.0 Authorization Frame
OAuth 2.0 の勉強のために認可サーバーを自作する - Qiita
逆に、RFC 6749 以外で定義されている認可フローをサポートする場合、新たに別のエンドポイントの実装が必要になることがあります。例えば CIBA（Client Initiated Backchannel Authentication）ではバックチャネル認証エンドポイント（backchannel authentication endpoint）、デバイスフロー（RFC 8628）ではデバイス認可エンドポイント（device authorization endpoint）の実装が求められます。 この記事では、認可エンドポイントとトークンエンドポイントを実装します。サポートする認可フローは認可コードフローのみ、サポートするクライアント・タイプはパブリックのみとします。 2. 注意点 下記の理由、および書かれていないその他の理由により、本実装は商用利用には適していません。 セキュリティー上必須
OAuth2.0 State の役割
はじめに 前回は OAuth2.0 の認可コードグラントフローの I/F についてまとめました。 その中でいきなり登場したStateにフォーカスしてまとめます。 アジェンダ 認可コードグラント(復習) CSRF のための state OAuth2.0 の CSRF(Cross-Stie-Request-forgery) state を使用した認可コードグラントフロー まとめ 認可コードグラント(復習) またか！って思われるかもしれませんが、認可コードフローはフローが長く どこの話してるのかわかりにくいので、書いています。 (毎回すこしづつ改修してるので更に見やすくなっている...はず...) CSRF 対策のための State RFC6749の state の説明にはっきりと CSRF 対策のために導入すべき、と記載されています。 The parameter SHOULD be used
OAuthやOpenID Connectで使われるstateパラメーターについて | SIOS Tech. Lab
◆ Live配信スケジュール ◆ サイオステクノロジーでは、Microsoft MVPの武井による「わかりみの深いシリーズ」など、定期的なLive配信を行っています。 ⇒ 詳細スケジュールはこちらから ⇒ 見逃してしまった方はYoutubeチャンネルをご覧ください 【6/19開催】Kong Community Japan Meetup #4 本イベントでは、Kong Inc. のVP of ProductであるReza Shafii氏もプレゼンターとして参加。当社からはアーキテクト マネージャーの槌野の登壇が決定！参加無料です!! https://column.api-ecosystem.sios.jp/connect/kong/1081/ 【6/21開催】開発者目線でのSBOMとの向き合い方 SBOMの導入から開発者がSBOMの作成・管理を自動で行っていくための方法（デモ）を紹介します。
KeycloakでOpenID Connectを使ってシングルサインオンをしてみる（認可コードフロー(Authorization Code Flow)編） - Qiita
KeycloakでOpenID Connectを使ってシングルサインオンをしてみる（認可コードフロー(Authorization Code Flow)編）SSOopenid_connectSingleSignOnKeycloak 今日やること Keycloakアドベント 17日目は、OpenID Connectの認可コードフローをやってみたいと思います。Relying Partyを作って、認可コードフローでシングルサインオンをしてみましょう。 というか、認可コードフローってなんだっけ？ こんなの。 事前準備 Keycloakは2日目の記事などを参考にしてインストールしておいてください。テストユーザーはこの記事の中で作ります。 Relying Party (RP) を作る OpenID Connectをやるなら、当然シングルサインオンするRelying Partyが必要なので、これから作って
KeycloakによるAPIセキュリティの基本
連載の1回目である今回は、Keyclooakの基本および、API保護が必要とされる背景について解説します。 サービスがより活発に利用されることを狙って、企業や公的機関によるサービスのAPI（Application Programming Interface）公開が広がっています。また、自組織内でもモバイルアプリケーション開発やシステム間連携を行いやすくするために、システムがAPIを提供することが多くなってきています。その際、APIは限られた人やシステムにだけがアクセス可能にする必要があるため、認証・認可のようなセキュリティ技術が必須になってきます。 認証・認可は、OAuth 2.0の枠組みに基づくことが一般的ですが、OAuthは自由度が高い仕様であるため、誤って実装・構築してしまうとセキュリティホールが作りこまれてしまいます。本記事では、近年急成長を遂げている認証・認可サーバOSSである「
OAuth 2.0 の認可レスポンスとリダイレクトに関する説明 - Qiita
はじめに この記事では、OAuth 2.0 の認可サーバーが返す認可レスポンスと、それに伴うリダイレクト処理について説明します。 動画解説のほうがお好みであれば、オンライン勉強会『OAuth & OIDC 勉強会 【認可リクエスト編】』の『3. リダイレクション』をご覧ください。 RFC 6749（The OAuth 2.0 Authorization Framework）には、アクセストークン発行フローが幾つか定義されています（参考：OAuth 2.0 全フローの図解と動画）。 それらのうち、認可コードフロー（RFC 6749, 4.1. Authorization Code Grant）とインプリシットフロー（RFC 6749, 4.2. Implicit Grant）では、クライアントアプリケーションが Web ブラウザを介して認可サーバーの認可エンドポイント（RFC 6749, 3
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 トークンを提示してきたとき、そのトークンのバリデーションを外
OAuth 認証を真面目に考える | DevelopersIO
認証とログインは別と捉えることで、その状態の維持に着目してその手法を考えましょう。OAuth 認証は2018年現在、必要悪としか言いようがありません。ぐぬぬ。ソーシャルログインであっても、Web サーバーで自前のセッションを管理してください。 永遠の生魚おじさん、都元です。学生時代、ロックバンド Harem Scarem の Mood Swings (1993年) っていうアルバムが好きでよく聞いてたんですけど、この前 Google Play Music で検索してみたらMood Swings II (2013年) っていうアルバムが出ていることに気づきました。なんと曲目が全て一緒で、妙なアレンジのリミックスになっていない、まさに「オリジナルのまま20年磨き続けたらこうなりました」みたいな仕上がりが最高でした。聴き比べて楽しんでいます。 さて、弊社は本日を最終営業日として、これから冬季休業
OAuth 2.0 クライアント認証 - Qiita
はじめに この記事では、OAuth 2.0 の『クライアント認証』について説明します。 RFC 6749 に記述されているクライアント認証方式のほか、クライアントアサーションやクライアント証明書を用いるクライアント認証方式についても説明します。 1. クライアント認証方式 1.1. トークンエンドポイント 認可サーバーがあります。 認可サーバーからアクセストークンの発行を受けたいクライアントアプリケーションがあります。 アクセストークンは、幾つかの例外を除き、認可サーバーのトークンエンドポイントから発行されます。そのため、認可サーバーはトークンエンドポイントを用意します。 クライアントアプリケーションは、アクセストークンの発行を受けるために、トークンエンドポイントにトークンリクエストを投げます。 認可サーバーは、トークンレスポンスを返します。この応答の中に、アクセストークンが含まれます。
Keycloakハンズオン - Qiita
version: "3" services: keycloak: image: jboss/keycloak:12.0.2 environment: KEYCLOAK_USER: administrator KEYCLOAK_PASSWORD: "00000000" ports: - 8080:8080 networks: - keycloak networks: keycloak: external: true 1-4. 起動確認 ブラウザを開き、http://localhost:8080にアクセスするとウェルカムページが表示されます。 2. 認証サーバーの設定 Keycloakの設定をしていきます。 2-1. 管理コンソールへのログイン 1-4でアクセスしたウェルカムページのAdministration Consoleをクリックしてください。 ログインページが表示されるので、KEYCL
OAuth 2.0 全フローの図解と動画 - Qiita
RFC 6749 (The OAuth 2.0 Authorization Framework) で定義されている 4 つの認可フロー、および、リフレッシュトークンを用いてアクセストークンの再発行を受けるフローの図解及び動画です。動画は YouTube へのリンクとなっています。 English version: Diagrams And Movies Of All The OAuth 2.0 Flows 追記 (2019-07-02) 認可決定エンドポイントからクライアントに認可コードやアクセストークンを渡す方法については、別記事『OAuth 2.0 の認可レスポンスとリダイレクトに関する説明』で解説していますので、ご参照ください。 追記（2020-03-20） この記事の内容を含む、筆者本人による『OAuth & OIDC 入門編』解説動画を公開しました！ 1. 認可コードフロー RF
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
OAuth & OIDC 入門編 by #authlete
GitHub - nextauthjs/next-auth: Authentication for the Web.