認可コードグラント RFC 6749で定義されるOAuthの認可コードグラントでは、認可サーバの実装として、認可エンドポイントとトークンエンドポイントの2つが必要です。リクエストは大きく分けて認可リクエスト (Authorization Request) およびトークンリクエスト (Access Token Request) の2つに分けられます。 全体のシーケンス図は以下の通りです。 PlantUMLのソースコード @startuml @startuml title 認可コードグラントにおけるシーケンス図 autonumber actor RO as "リソースオーナー" participant UA as "User-Agent" participant C as "クライアント" participant AS as "認可サーバ" participant RS as "リソースサーバ
Ubie プロダクトプラットフォーム所属の nerocrux です。今回は Ubie において、 LINE ログインを成功させるために工夫したことをいくつか紹介したいと思います。 面白いこともすごいこともやってないし、対象読者もよくわかりませんが、興味があったら読んでみてください。 はじめに 症状検索エンジン「ユビー」について Ubie では、症状検索エンジン「ユビー」（以下、ユビーと呼ぶ）という一般ユーザー向けのサービスを展開しています。ユーザーが簡単な質問を回答することで、関連する病名や、適切な受診先情報を得ることができるサービスとなっています。 ユビーは Web ブラウザ経由で利用されることが多いですが、iOS / Android のネイティブアプリも提供しています。 ユーザーがユビーを利用する際に、ユビーのアカウントを作成することで、一貫性のある問診・受診・受診後のフォローアップ体
2023/10/05 Offersさんのイベントでの資料です。 https://offers.connpass.com/event/295782/ イベント後の満足度アンケート（5点満点）の結果は以下になります。 5点: 49% 4点: 39% 3点: 8% 2点: 4% こちらの…
Concepts. Architecture. Best Practices. A series of technical guides for building application authorization. Authorization is a critical element of every application, but the problem is: there’s limited concrete material available for developers on how to build authorization into your app. To help developers build these systems and features, we built Authorization Academy.
// auth.ts import NextAuth from "next-auth" import GitHub from "next-auth/providers/github" export const { auth, handlers } = NextAuth({ providers: [GitHub] }) // middleware.ts export { auth as middleware } from "@/auth" // app/api/auth/[...nextauth]/route.ts import { handlers } from "@/auth" export const { GET, POST } = handlers // src/auth.ts import { SvelteKitAuth } from "@auth/sveltekit" impor
Account hijacking using “dirty dancing” in sign-in OAuth-flows Combining response-type switching, invalid state and redirect-uri quirks using OAuth, with third-party javascript-inclusions has multiple vulnerable scenarios where authorization codes or tokens could leak to an attacker. This could be used in attacks for single-click account takeovers. Frans Rosén, Security Advisor at Detectify goes t
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに OAuth 2.0 の認可レスポンスは、登録済みの『リダイレクト URI』宛に返却されます。詳細は『OAuth 2.0 の認可レスポンスとリダイレクトに関する説明』を参照してください。 複数のリダイレクト URI が登録されている場合、どのリダイレクト URI に認可レスポンスを返して欲しいかを、認可リクエスト時に指定する必要があります。この目的のために、redirect_uri リクエストパラメーターが用いられます。 認可サーバーは、redirect_uri リクエストパラメーターで指定された URI が、事前登録されたリダ
オープンリダイレクト（Open Redirect）攻撃は、リダイレクト処理の実装不備を悪用し、被害者となるユーザを意図しない URL に誘導をする攻撃手法・脆弱性です。 意図しないリダイレクトを発生させるだけですと、大きな問題は起こせないと思われるかもしれませんが、正規ドメインから悪性ドメインへ意図しない誘導を行える場合、フィッシング詐欺などに悪用される可能性があります。 フィッシング詐欺に悪用された際のオープンリダイレクトは、危険度が高まります。 本記事では、オープンリダイレクトの原因と対策について触れたあと、対策方法や、開発者としてこのオープンリダイレクトを見つける方法についてご紹介します。 また、オープンリダイレクトを使った高度な攻撃手法（OAuth2 を狙ったオープンリダイレクト）の例について解説します。 オープンリダイレクトの概要 オープンリダイレクトは、「正規サービスのドメイ
OAuth 2.0 Security Best Current Practice Abstract This document describes best current security practice for OAuth 2.0. It updates and extends the OAuth 2.0 Security Threat Model to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0.¶ Status of This Memo This Internet-Draft is submitted in full confor
【書評】雰囲気でOAuth2.0を使っているエンジニアがOAuth2.0を整理して、手を動かしながら学べる本 #技術書典7 技術書典7で頒布された「雰囲気でOAuth2.0を使っているエンジニアがOAuth2.0を整理して、手を動かしながら学べる本」を読んでみたのですが、良かったので紹介します。 以下で購入可能です。 雰囲気でOAuth2.0を使っているエンジニアがOAuth2.0を整理して、手を動かしながら学べる本 雰囲気でOAuth2.0を使っているエンジニアがOAuth2.0を整理して、手を動かしながら学べる本 すごくざっくり言えば、OAuth 2.0 ってなんなの？と、実際にサービスのエンドポイントを叩いて各フローを実際に体験するチュートリアルから構成されています。 私が特に良いなと思ったのは、 実際に存在するサービスを使った例に合わせて説明が進むので、それぞれのロールが「そもそも
サーバーは、受け取ったクライアント証明書の主体識別情報が事前登録されているものと一致することを確認し、もってクライアント認証とします。 このクライアント認証方式には tls_client_auth という名前が与えられています（MTLS, 2.1.1. PKI Method Metadata Value）。 なお、クライアント証明書には OAuth 2.0 の文脈におけるクライアント ID は入っていないので、クライアント証明書だけではクライアントを特定することはできません。そのため、クライアント証明書を用いるクライアント認証をおこなう際は、別途クライアント ID をリクエストに含める必要があります。通常は client_id リクエストパラメーターが使用されます。 1.8. self_signed_tls_client_auth クライアント証明書を用いるクライアント認証において、PKI
認可と認証技術 OAuth 1.0、OAuth 2.0 および OpenID Connect に関するスライドをアップしました。 アプリ開発で知っておきたい認証技術 - OAuth 1.0 + OAuth 2.0 + OpenID Connect - from Naoki Nagazumi www.slideshare.net 開発している Web アプリで、OAuth 1.0 や OAuth 2.0 および OpenID Connect の認可と認証技術を組み込んだ時に、あれこれ調査して知り得た技術をまとめたものです。 130ページくらいの力作です！ぜひご覧ください。 デモ これのデモはこちらにあります AuthsDemo デモのソースコードはこちらです。 GitHub - ngzm/auths-demo: This is a demo program with using OAuth
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
