はじめに LLMと外部データソースを統合する際、ツールの認証をどうするのか悩みます。たとえば、MyGPTsのActionsではOAuth 2.0による認証[1]が実装されています。 MyGPTsではこのようにOAuth設定が可能 これは結構便利で、Google Apps Scriptを作り、組織内ユーザーにアクセスを限定した形でデプロイすれば、スプレッドシートやGmailとのセキュアな連携が、認証フロー含めてMyGPTs上で完結します。 Apps Scriptは呼び出し元を制限できる。呼び出しにはOAuth2が必要。 一方でClaude Desktopも使えるGoogle Workspace連携MCPサーバーの作例を見ると、APIキー認証のものか、手元で認証フローを走らせるもので、Claude Desktop上で認証・認可できるものは管見の限りありません。 この記事は、Claude Des
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
こんばんは。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
複数のクラウドサービスを利用している（マルチクラウド）など、単純には閉域網を構築できない環境でマイクロサービスアーキテクチャを採用する場合には、サービス間の認証認可が必要となる。この場合のサービス間の認証認可方式を決める参考となる、OSSやSaaS、Webサービスで採用方式ついて整理した。 Istio サービスメッシュの実装として有名なIstioではサービス間通信を以下のように制御できる。 Istioの認証認可では認証主体がService Identityというモデルで抽象化され、KubernatesやIstioで定義するService Accountに加えて、GCP/AWSのIAMアカウントやオンプレミスの既存IDなどをService Identityとして扱うことができる。 サービス間の認証 (Peer Authentication) は、各サービス (Pod) に設置するSideca
GAE/Go をちょいちょい触っている。 その中の Pull queue を試そうとしたとき、OAuth2 のトークンが必要になったので取得したメモ。 手順 Google Could Platform の API Manager から認証情報（ClientID, Secret）をつくる 下記コマンドを叩く。 [utahta@mbp google-oauth2]% go run oauth2_token.go Input ClientID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.apps.googleusercontent.com Input Secret: XXXX-XXXXXXXXXXXXXXXXXXXXXX Input Scopes: https://www.googleapis.com/auth/taskqueue,https://www.goo
Send feedback Programmatic authentication Stay organized with collections Save and categorize content based on your preferences. This document describes how to authenticate to an IAP-secured resource from a user account or a service account. Programmatic access is the scenario where you call IAP protected applications from non-browser clients. This includes command line tools, service-to-service c
oauth2パッケージ go言語でoauth2を扱うのに便利なoauth2パッケージがあります。 今回は、これを使ってみたいと思います。 例として、Googleフォト(Picasa)のAPIを扱います。 ソースは下記を参照。 import ( "bufio" "fmt" "io/ioutil" "log" "os" "golang.org/x/oauth2" "golang.org/x/oauth2/google" ) func main() { //ClientIDやClientSecretはGoogle API Console からコピーしてきます。 //Endpointはgoogle、github、facebookなどがoauth2配下のパッケージに用意されています。 config := oauth2.Config{ ClientID: "xxxxxxxxxxx", ClientSe
ども、大瀧です。 先日リリースされたALBの認証機能、ブログではGoogle認証と連携する様子をご紹介しました。 ただこの構成は任意のGoogleアカウントの認証を通してしまうので、Google Appsの自組織のメールアドレスのみ許可したいというような業務向けのユースケースだとターゲット側で認可機能を実装しなくてはならず、片手落ち感がありました。 そこで本記事では、認証先にCognitoユーザープールを設定し、Lambdaトリガーでメールアドレスを制限する構成をご紹介します。 構成の目的と概要 ALBの認証機能を用いて、Webアプリケーションへのアクセスを制限します。前回の記事で指定したOpenID ConnectによるGoogle認証の代わりにAmazon Cognitoを指定し、そのCognitoユーザープールの外部IDプロバイダとしてGoogle認証を連携させます。 わざわざCog
bitly/oauth2_proxyを用いて，ウェブアプリケーションに手っ取り早くOAuth2認証を導入するという話です． oauth2_proxyは良い感じでOAuth2による認証を肩代わりしてくれる君で，何らかのリバースプロキシの認証機構と組み合わせて利用すると簡単にOAuth2ログインを実現することができます． 今回は例としてKibanaにGoogleのOAuth2ログインを導入してみたいと思います． 構成 Kibana bitly/oauth2_proxy nginx +------+ +-------+ +--------------+ +--------+ | | | | ----auth----> | | | | | user | --request--> | nginx | | oauth2_proxy | <--auth--> | Google | | | | | <--
OAuth2 でレスポンスタイプがコードもしくはトークンの場合、ブラウザで認証を行ってコードやトークンを自前サーバで受け取る事になる。モバイルアプリだと組み込みブラウザが前提になっておりリダイレクトの最終 URL からアクセスコードやトークンを得る。ただコマンドラインアプリの場合、認証の為に起動したブラウザの最終 URL を得る方法はない。また1コマンドラインアプリケーションの為にドメイン付きのコールバックサーバを用意するのも面倒だし、作ったサーバをユーザに信用して貰う必要がある。あとそもそも外部のサーバで受け取ったトークンをどうやってコマンドラインアプリに渡すかという問題がある。 そこで使うのがローカルサーバを立てる方法。認証後のコールバック先をコマンドラインアプリから起動したローカルサーバにし、そこにリダイレクトさせてアクセストークンを貰い保存する。 今日はこれが伝わり易い用に Mic
なんですかこれは！ New attack bypasses HTTPS protection on Macs, Windows, and Linux DHCP につなぐと PAC ファイルがダウンロードされて HTTPS であろうとアクセス先の Full URL は漏れるですって？ Web Proxy Autodiscovery ですって？ チョットニホンゴデオネガイシマス ってことで、まぁこれが実際どれくらい簡単に実現できる攻撃パターンなのかは他のセキュリティ業界の方々に後で聞くとして、この記事でも触れられてる OpenID Connect とか OAuth2 への影響について、ちょっとまとめておきましょうか。 Authorization Request & Response が漏れる response_mode=form_post なんていうのも一部ありますが、基本 OAuth2 /
この記事は1年以上前の古い記事です。現状に即していない記述の場合があります。あらかじめご了承ください。 _ Chromebookが企業・教育機関向けに国内発売だそうです。 Google Enterprise Japan 公式ブログ: 企業や教育機関で Chromebook をご利用いただけるようになります。: http://googleenterprise-ja.blogspot.jp/2014/07/chromebook.html 一般人が、Gentooプリインストールマシンを使う世界が来たと考えると胸が熱くなりますね。 ということで、DebianでもChromeOSもどき作れるかなと妄想したところ、ChromeBookのいいところは認証がGoogleアカウントでできるじゃないかと思ったですよ。で、それを実現するならOpenIDかOAuthじゃないかと思ってググったら、作ってた人いたよ!
こんにちは、ritouです。 やっと”なんちゃらAdvent Calendar”がおさまり、これからは”一年を振り返って(遠い目”みたいな記事が増えることでしょう。その間のタイミングを狙います。 何の話か mixi Platformが導入したっていうOAuth 2.0のCSRF対策拡張を使ってみた - r-weblife の最後にちょっと書いたんですけど、モバイルアプリでOAuth 2.0を使う際にやっかいな問題が残ってました。 今回は、「ネイティブアプリケーションからOAuth 2.0を使うとき、特定の条件下において、正規のClientではない悪意のある第3者に認可応答を持って行かれて、その結果Access Tokenを取得できちゃうリスクがあるよね。どうしようか。」っていう話です。 条件っていうのは、 OAuth 2.0のClientはネイティブアプリケーションであり、Client C
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
