【プログラマ英語】それ認証って意味じゃないですよ（厳密には） - Qiita
Googleの"2段階認証"が､原文だと '2-Step Verification' って書かれてたので、ちょっと書いておきます。 (Googleの場合は公式で、2段階認証って読んじゃってるんでいいんですけど...) 日本語で認証って訳されてるものにこんなのがあります。 Authentication Authorization Verification このなかで、いわゆる" 認証 "と呼べるのは実は Authenticationだけです。 日本だと認証とまとめてしまっている故にOAuthをログイン代わりで使ってセキュリティホール空けてる方とかもいらっしゃいますが、 http://www.sakimura.org/2012/02/1487/ (※1) 英語圏だと逆に意味の違いゆえに'authentication'と'authorization'どっち？みたいな話が盛り上がります。 http
GitHub の OAuth 実装の仕様違反とセキュリティ上の考慮事項 - Qiita
本稿は GitHub Docs の "Authorizing OAuth Apps" ページに書かれている情報に基づいています。英語版はこちら → "Spec Violations in GitHub OAuth Implementation and Security Considerations" 仕様違反箇所 認可リクエストの response_type リクエストパラメーターがない。当パラメーターは必須である。RFC 6749 (The OAuth 2.0 Authorization Framework) Section 4.1.1 (Authorization Request) 参照。 トークンレスポンスのデフォルトフォーマットが application/x-www-form-urlencoded のようである。フォーマットは常に application/json でなければならな
OAuth2.0拡張仕様のPKCE実装紹介 〜 Yahoo! ID連携に導入しました
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは。 サービス統括本部の都筑(@kazuki229_dev)です。 新卒4年目で普段はYahoo! ID連携のサーバーサイド、iOSのSDKの開発などを担当しています。 Yahoo! ID連携とは、Yahoo! JAPANのシングルサインオンやユーザーの属性情報を取得するID連携の仕組みです。 Yahoo! ID連携とは このYahoo! ID連携ではPKCEというOAuth2.0の拡張仕様を実装しました。 https://developer.yahoo.co.jp/changelog/2019-12-12-yconnect.html そこで、PKCEの基本的な話と、実装の際に調査したことをまとめてみました。 PKCEとは
OAuthにおける認可コード横取り攻撃とその対策
OAuthにおける認可コード横取り攻撃とその対策 Jul 5, 2021 前回の記事で示したように、カスタムURLスキームを偽装した不正アプリは正規アプリへのディープリンクを乗っ取れる。この挙動の悪用シナリオとして、正規アプリと認可サーバー間のOAuthフローにおける認可コード横取り攻撃が知られている。この攻撃への対策を把握するためにiOS環境でシナリオを再現し、PKCEの有効性を確認した。 要約 OAuth 2.0の拡張機能であるPKCEを導入することで認可コード横取り攻撃を無効化できる。OAuth 2.0の仕様では、認可サーバーはネイティブアプリをクライアント認証できない。そのため、認可サーバーは認可コードを横取りした不正アプリと正規アプリを識別できない。しかし、PKCEの仕組みにより認可サーバーは正規アプリを識別できるようになり、認可コード横取り攻撃の検知が可能となる。 ネイティブア
SSHログイン時に公開鍵認証とGoogle OAuthで多要素認証する | ten-snapon.com
# ブラウザで認証後表示されたコードをペーストする Please type code:xxxxxxxxxxxxxxx sshでサーバにログインする際に、まず公開鍵認証が行われ、正解するとたーみなるに、このURLを開いてくれというメッセージが出ます。 https://accounts.google.com/o/oauth2/auth?access_type=offline&client_id=xxxxxxxx-xxxxxxxxxxx.apps.googleusercontent.com&redirect_uri=uxxxxx 上記の部分ですね。これをブラウザに貼り付けて、Googleの認証を超えると、あるコードが払い出されるので、それをターミナルに貼り付けると無事ログインできます。また、ログイン後はトークンが有効期限のうちは再度oAuthする必要はありません。 インストール方法 OAuth
「GoogleがGmailの内容を外部企業に読ませている」という記事について - @stomita daily (or monthly, yearly)
Forbes Japanに以下のような記事が掲載された。 forbesjapan.com これについて記事を読んだ人たちのTwitter等での反応を見ていたのだけれど、その反応にちょっと違和感を感じたので、今回少し書いている。 まず最初の反応として、NewsPicksでのコメントを見てみる。 newspicks.com 「メール内容を読ませていいと同意した覚えはない」というコメントが多く、そこから転じて「Gmailは守秘が必要な用途で使うべきでない」「無料のサービスを使うということはこういうことなんだ」のような意見も見られる。 一方、はてブでの反応は、流石に技術者が多いコミュニティということもあり、ちょっと調子は異なっている b.hatena.ne.jp 何事かと思ったらOAuthのことだったｗ - gogatsu26のコメント / はてなブックマーク OAuth2で同意とってるなら普通じ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「GitHub」から非公開リポジトリなどのデータが流出 ～「npm」にも被害／「Heroku」「Travis-CI」発行のOAuthトークンが盗難・悪用される