Skip to content
This repository has been archived by the owner on Apr 28, 2022. It is now read-only.

Auth: define authentication protocol #1

Open
oorlov opened this issue Oct 10, 2013 · 7 comments
Open

Auth: define authentication protocol #1

oorlov opened this issue Oct 10, 2013 · 7 comments

Comments

@oorlov
Copy link
Contributor

oorlov commented Oct 10, 2013

No description provided.

@jesper-sjovall
Copy link
Contributor

I can see some different method to create a authentication protocol based on what goal we want to reach on use a authentication protocol.

  • The most simple way would be use password/secret token between two servers, and the password will be unique for each server-to-server link.
  • Cryptographic signature as OpenSSL but this request a loot more work compared to the password method.
    The problem with a cryptographic signature we have in this case determine how the signing process will work.
  • OAuth, is stronger then use of Password but do not protect against Man In Middle attacks. base on OAuth only do not handle Cryptographic signature what I can understand.

I think we need to identify what goal we want reach here?

  • Identify server/client Id
  • Protect data to be accessible for unauthorized.
  • Protect data to be tampered with by third party.

@morozstepan
Copy link

Hello there!
I suppose, the ideal solution is Oauth authorization, with data sent by https. So it would be protected from third party and as it's extendable, we can make clients with different permissions.
How do you think, is this a big deal to setup pure OAuth authorization system? Yandex already have one, but will it be easy for other stores?

@jesper-sjovall
Copy link
Contributor

Yes, probably your is right here, but way must we use a third party for identify a server to server connection?
Or do I misunderstand some basic about Oauth?

I think this is secure enough to only use password/secret token and https for encryptions, and this will be more simply then OAuth that for use will be some job to implements.

@morozstepan
Copy link

Hi!
Think I know, what to do.
In exchange protocol, we'll specify "access token" - a string, must be provided to access data.

  1. Those stores, who have OAuth setup on their servers, can make pure accounts with login and password and give them OAuth Tokens from their server (no third party server needed). It's more flexible - any token may be invalidated (by store, who is providing content), and can be renewed by client, getting the content - the token is given for login/password pair. The reason to use it: login and password is kept in secret, may be reset by both client and server, and if token is stolen, there's no problem to renew it.
  2. Those stores, who don't have OAuth server, or don't want to implement it, just give some unique secret token. They will need to implement some db for storring these tokens, make some administrative interface to support it. All this stuff is basically already implemented in OAuth servers - so, if store don't want OAuth, it implements token-giving system itself.
    What do you think?

@jesper-sjovall
Copy link
Contributor

It sound good, This will be the must easy way to go for all of us.

A quested here for us that not know to much about OAuth, if my store only support case 2,
How will my store verify a other store that use OAuth?

In other case the summary here will be.

  • Server To Server link talk over HTTPS ( for encryption )
  • We use a "secret token" for identify and verify server to server access that also is compatible with OAuth
    that will do this possible for they stores that support OAuth use it and for they that not support OAuth use
    only a "secret token".

Or have I misunderstand some parts here?

@morozstepan
Copy link

So, there are 2 parts of task.

  1. Getting token for access. It will not be described in exchange protocol, different stores may implement it different way. Somebody will maintain own database with tokens and give the tokens to users "manually". Somebody will support OAuth server and use it. Nevertheless, it looks like following: store, who wants access goes to another store and asks for token (somehow). Store who gave token can then validate it (also, somehow - from database or OAuth implementation).
  2. Accessing the data - described in exchange proto. It will require access token. You will need to authorize tokens, that you gave before.

Let's see example:
You have no OAuth setup. And Yandex have. You want to integrate with Yandex.
You generate some secret token for Yandex and give it to Yandex. So, when Yandex comes to your server, you will be able to authorize it. Then you need to access Yandex. To do it, Yandex setups your account, with login and password, and describes procedure of getting OAuth token. It's simple - just another http request - you pass login/password and get token. Then you use this token when accessing Yandex.

@jesper-sjovall
Copy link
Contributor

Ok, it sound good, I Think we will go for this solutions, this will be a good
compression between security and simplicity.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Development

No branches or pull requests

3 participants