2012-03-21 10 views
2

私はOAuthを取り巻く文献に固執し混乱しています。 OAuthプロバイダのtwitterに接続したいとしましょう。そして、私たちはmysite.comを持っています、それはいろいろなユーザーがいて、その中にはTwitterアカウントを持っているものもあります。ユーザーごとに個別のコンシューマーキーと個別のコンシューマーシークレットが必要ですか? 1組だけですか?Oauthの消費者トークンと秘密はユーザー固有のものですか?

答えて

4

コンシューマキーと秘密のペアは、アプリケーション固有のものであり、各アプリが一つのキー/秘密のペアになります。アプリはモバイルアプリ、ウェブサイト、またはあなたのコンピュータに隠れているスクリプトに過ぎません。たとえば、Twitterには、Android用Twitter、iOS用Twitter、Mac用Twitterのコンシューマーキー/シークレットがあります。

すべてのユーザは、具体的には、各アプリケーション(別名コンシューマキー/秘密ペア)を承認しなければならないと一意にユーザがその特定のコンシューマキーを承認したことを識別し、アクセストークンとシークレット対を有することになります。

+0

明確にするために、各アプリは、アプリの消費者キー/シークレットと、それぞれの* _instance_を持たないことを意味しますか?たとえば、Android用のTwitterには鍵ペアがありますが、携帯電話と携帯電話のアプリでは同じ鍵ペアが使用されます。 – iain

+0

Android用のすべてのTwitterのインストールでは、同じ鍵/秘密のペアが使用されます。 – abraham

1

はい。

リクエストトークンは、特定のユーザーがそれを承認するまで消費者(Mysite)とのみ関連付けられます。

アクセストークンは、コンシューマ(Mysite)とそれに該当するユーザーを認識します。その所有者はMysiteとして識別し、そのユーザーの代わりに操作を実行できます。ここで


はOAuthの-PHPはそれを実装する方法である:http://code.google.com/p/oauth-php/source/browse/trunk/library/store/mysql/mysql.sql

# 
# ////////////////// SERVER SIDE ///////////////// 
# 

# Table holding consumer key/secret combos an user issued to consumers. 
# Used for verification of incoming requests. 

CREATE TABLE IF NOT EXISTS oauth_server_registry (
    osr_id      int(11) not null auto_increment, 
    osr_usa_id_ref    int(11), 
    osr_consumer_key   varchar(64) binary not null, 
    osr_consumer_secret   varchar(64) binary not null, 
    osr_enabled     tinyint(1) not null default '1', 
    osr_status     varchar(16) not null, 
    osr_requester_name   varchar(64) not null, 
    osr_requester_email   varchar(64) not null, 
    osr_callback_uri   varchar(255) not null, 
    osr_application_uri   varchar(255) not null, 
    osr_application_title  varchar(80) not null, 
    osr_application_descr  text not null, 
    osr_application_notes  text not null, 
    osr_application_type  varchar(20) not null, 
    osr_application_commercial tinyint(1) not null default '0', 
    osr_issue_date    datetime not null, 
    osr_timestamp    timestamp not null default current_timestamp, 

    primary key (osr_id), 
    unique key (osr_consumer_key), 
    key (osr_usa_id_ref) 

# , foreign key (osr_usa_id_ref) references any_user_auth(usa_id_ref) 
#  on update cascade 
#  on delete set null 
) engine=InnoDB default charset=utf8; 


CREATE TABLE IF NOT EXISTS oauth_server_token (
    ost_id     int(11) not null auto_increment, 
    ost_osr_id_ref   int(11) not null, 
    ost_usa_id_ref   int(11) not null, 
    ost_token    varchar(64) binary not null, 
    ost_token_secret  varchar(64) binary not null, 
    ost_token_type   enum('request','access'), 
    ost_authorized   tinyint(1) not null default '0', 
     ost_referrer_host  varchar(128) not null default '', 
     ost_token_ttl   datetime not null default '9999-12-31', 
    ost_timestamp   timestamp not null default current_timestamp, 
    ost_verifier   char(10), 
    ost_callback_url  varchar(512), 

     primary key (ost_id), 
    unique key (ost_token), 
    key (ost_osr_id_ref), 
     key (ost_token_ttl), 

     foreign key (ost_osr_id_ref) references oauth_server_registry (osr_id) 
     on update cascade 
     on delete cascade 

# , foreign key (ost_usa_id_ref) references any_user_auth (usa_id_ref) 
#  on update cascade 
#  on delete cascade   
) engine=InnoDB default charset=utf8; 
+0

明確にする。私はリクエストトークンについて尋ねていません。私は消費者の鍵と秘密について尋ねています。 – Zombies

+0

コンシューマーキーと秘密**はコンシューマーを識別します**。だから、消費者ごとに1つしかありません。 – aitchnyu

+0

@aitchnyu:それは消費者ごとに複数ある可能性があります。プロトコルは、その確率を考慮しなかったので、 – zerkms

関連する問題