タグ

認証に関するs4_baのブックマーク (6)

  • OAuth認証とは何か?なぜダメなのか - 2020冬 - r-weblife

    こんばんは。ritouです。 Digital Identity技術勉強会 #iddance Advent Calendar 2020 1日めの記事です。 qiita.com 初日なのでゆるふわな話をしましょう。 何の話か もうだいぶ前ですね。9月のお話です。こんなTweetを見かけました。 社内Slackにいる「OAuth認証」と書くと訂正してくれるbotが丁寧な解説をするようになっていた 認証(Authentication)と認可(Authorization)は間違えやすいわりにミスると甚大な被害をもたらしがちなので、常日頃から意識を高めていきたいですね pic.twitter.com/oVQxBgZcHS— greenspa (@greenspa) 2020年9月28日 このbotに対する思うところはもう良いです。 今回は、「OAuthの仕様に沿ってID連携を実装するいわゆる"OAut

    OAuth認証とは何か?なぜダメなのか - 2020冬 - r-weblife
  • authorization_code_flow

    authorization_code_flow 1�U�U ��V�U @startuml UA -> App: /login UA <-- App: Redirect UA -> 認可サーバー: /auhorize UA <- 認可サーバー: ログインページ表示 UA -> 認可サーバー: ログイン UA <- 認可サーバー: 認可(AppにXXXを許可しますか? UA -> 認可サーバー: OK UA <-- 認可サーバー: Redierct UA -> App: /callback?code=xxx&state=xxx App -> 認可サーバー: /token に認可コードを渡す App <- 認可サーバー: AccessToken App -> App: セッションにAccessToken保存 UA <- App: ログイン完了 @enduml bad_practice_auth

    authorization_code_flow
  • 【Yahoo! ID連携】実装方法再確認のお願い - Yahoo!デベロッパーネットワーク

    Yahoo! ID連携(Yahoo! ID連携 v1,v2)をご利用の皆様 いつもYahoo! ID連携をご利用いただきありがとうございます。 不正アクセス防止のために改めて実装方法のご確認をお願いいたします。 ■Yahoo! ID連携を利用しサーバーサイドでユーザー認証を行う場合 下記のような実装方法をされている場合は実装のご変更をお願いいたします。 ▼脆弱性のある実装方法 フロントエンドJavaScriptやiOS,Androidのネイティブアプリで ユーザー識別子(sub)を取得しサーバーサイドへ送信するような実装をしている場合、 第三者のユーザー識別子を送信することでそのユーザーとしてログインできてしまう可能性があります。 そのため、上記のような実装は推奨しておりません。 ▼推奨する実装方法 フロントエンドJavaScriptやiOS,Androidのネイティブアプリではユーザ

    【Yahoo! ID連携】実装方法再確認のお願い - Yahoo!デベロッパーネットワーク
  • 各社のログインAPIで返ってくるIDは何であるのかと、PPIDの現状について

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    各社のログインAPIで返ってくるIDは何であるのかと、PPIDの現状について
    s4_ba
    s4_ba 2019/07/16
  • OAuth 2.0 クライアント認証 - Qiita

    はじめに この記事では、OAuth 2.0 の『クライアント認証』について説明します。 RFC 6749 に記述されているクライアント認証方式のほか、クライアントアサーションやクライアント証明書を用いるクライアント認証方式についても説明します。 1. クライアント認証方式 1.1. トークンエンドポイント 認可サーバーがあります。 認可サーバーからアクセストークンの発行を受けたいクライアントアプリケーションがあります。 アクセストークンは、幾つかの例外を除き、認可サーバーのトークンエンドポイントから発行されます。そのため、認可サーバーはトークンエンドポイントを用意します。 クライアントアプリケーションは、アクセストークンの発行を受けるために、トークンエンドポイントにトークンリクエストを投げます。 認可サーバーは、トークンレスポンスを返します。この応答の中に、アクセストークンが含まれます。

    OAuth 2.0 クライアント認証 - Qiita
  • アプリで「ログインしっぱなし」はどのように実現されているか? - Qiita

    このツイートを見て、「アプリで再ログインを頻繁要求されるってユーザビリティ良くないな。」と思ったのですが、普段裏側の仕組みは意識していなかったりテックリードの方に任せきりだったりしていたので、これを機に調べてみました。 そもそもスマホアプリ の時代、もはやauthenticationですらないと思うのよね。(何を言ってるかわからねえだろうと思うが。) — Hiromitsu Takagi (@HiromitsuTakagi) 2019年7月8日 この記事は「アプリでログインしっぱなしは、どのように実現されるの?」という疑問と調べた結果を共有するために書いていきます。 間違いや「もっとこんな仕組みが使われてるよ!」等のツッコミがあれば、どしどし貰えると助かります! 疑問1. アクセストークンという仕組みとは? 「なぜアクセストークンという概念が必要なのか?」 モバイルアプリでユーザー認証をし

    アプリで「ログインしっぱなし」はどのように実現されているか? - Qiita
  • 1