Потребительские токены и секреты Oauth специфичны для пользователя?

Question

Я застрял и запутался в литературе вокруг OAuth.Допустим, мы хотим подключиться к провайдеру OAuth, твиттеру.И у нас есть mysite.com, у него есть разные пользователи, и у некоторых из них также есть твиттер-аккаунт.Нужен ли отдельный ключ потребителя и / или отдельный ключ потребителя для каждого пользователя, или у меня есть только 1 пара из них?

Answer 1

Ключ потребителя и секретная пара зависят от приложения, и каждое приложение будет представлять собой одну пару ключ / секрет.Приложение может быть мобильным приложением, веб-сайтом или просто скриптом, скрывающимся на вашем компьютере.Например, у Twitter есть другой потребительский ключ / секрет для Twitter для Android, Twitter для iOS и Twitter для Mac.

Каждый пользователь должен авторизовать каждое приложение (или пользовательский ключ / секретная пара) специально и будет иметьтокен доступа и секретная пара, которые однозначно определяют, что пользователь авторизовал этот конкретный ключ потребителя.

Answer 2

Да.

Токен запроса связан только с потребителем (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;