First impressions of oauth saved json types

Readme.md

Couchbase OAuth types

Ok, so first impressions are the way that the data is being saved in couchbase is not conforming to some of the conventions we made regarding required fields and keys.

All keys saved to the database should be in the format [reverse domain]_[sigular type]_[int id or urlsafe string id] or as an example com.example.www_client_web-app. URLsafe ID's should be composed of a-z A-Z 0-9 or - but not _.

All objects saved in the DB should have the following required properties...

{
"id":"int id or urlsafe string id", // always a string, only the end of the key
"type":"sigular type" // such as client
}

So for example

{
"id": "web-app",
"type": "client"
}

Currently the client looks like this in the DB

KEY: web_app
PRODUCES:
{
  "Id": "ios_app",
  "Secret": "ljhf34ndc2",
  "RedirectUri": "http://ios_app/redirect",
  "UserData": null
}

but really it should look something like

KEY: com.example.www_client_web-app
PRODUCES:
{
  "id": "web-app", // small case dictionary keys
  "type": "client", // type is required in all objects
  "secret": "ljhf34ndc2", // this should be salted and hashed
  "redirectUri": "http://ios_app/redirect",  // this is fine, but not used at present
  "scopes": [ // a full list of allowed scopes for this client.  
    "user.user.read", "admin.user.read", "user.user.write", "admin.user.write"
  ],
  "grantTypes": [ // a full list of allowed grant types for this client.  (this should be possible with osin, let me know if not)
    "password", "refresh"
  ]
}

The key in particular and the lack of type will cause issues finding all key objects

Currently the token looks like this in the DB

KEY: a_l0dQj1tyRgu37DVGojBVfw
PRODUCES:
{
  "Client": {  //Saving client data, especially the secret shouldn't be required by any user of this token, is it an osin thing?
    "Id": "web_app",
    "Secret": "alflrwfj3q4",
    "RedirectUri": "http://web_app/redirect",
    "UserData": null
  },
  "AuthorizeData": null,  // shouldn't be required
  "AccessData": null,     // shouldn't be required
  "AccessToken": "l0dQj1tyRgu37DVGojBVfw",
  "RefreshToken": "1d9oih9bRsC8LCN8wJAd7w",  // probably should be seperate entity
  "ExpiresIn": 3600,  // Should probably be set by couchbase
  "Scope": "foo bar baz", // Should probably be an array
  "RedirectUri": "http://web_app/redirect",  // not required in token
  "CreatedAt": "2016-06-22T12:17:02.538254312+01:00",
  "UserData": null  // prob don't save the whole user object, just what is required further down the line
}

Should probably be two objects and look something like

KEY: com.example.www_token_l0dQj1tyRgu37DVGojBVfw
COUCHBASE EXPIRY SET TO: 3600
PRODUCES:
{
  "id": "l0dQj1tyRgu37DVGojBVfw", // presumably this is the bearer token which grants access to an endpoint?  not required because it's in the key, but nice to have
  "type": "token",
  "client": { // not required but useful for bug tracing
    "id": "web_app" 
  },
  "scopes": [
    "user.user.read", "user.user.write" // only the direct scopes which this token grants access to.
  ],
  "user": {
    "id": "test@test.com",
    "tags": [ "foo", "bar", "baz" ]
  }
}

KEY: com.example.www_refreshToken_1d9oih9bRsC8LCN8wJAd7w
COUCHBASE EXPIRY SET TO: 604800  // reset every time refresh token is used
PRODUCES:
{
  "id": "1d9oih9bRsC8LCN8wJAd7w", // The refresh token.  not required because it's in the key, but nice to have
  "type": "refreshToken",
  "client": { // not required but useful for bug tracing
    "id": "web_app" 
  },
  "scopes": [
    "user.user.read", "user.user.write" // below needed info for creating new token.
  ],
  "user": {
    "id": "test@test.com",
    "tags": [ "foo", "bar", "baz" ]
  }
}

Although it doesn't look like users are being saved to the database yet, I'd expect them to look something like the following.

KEY: com.example.www_user_test@test.com
PRODUCES:
{
    "id": "test@test.com",
    "type": "user",
    "email": "test@test.com",
    "password": "fjdklajskdlfjklds34758347589fdjkslfjklsj" // Salted and hashed please.  Passwords sent to the API should be plain text protected by SSL and salted and hashed on the server or compaired to saved DB hash.  Strong salt should be used with the user id mixed in so hashes can't be transferred between user.  Password hashes shouldn't be displayed in any Get request.
    "tags": [
        "foo",
        "bar",
        "baz"
    ],
    "scopes": [
        "user.store.read",
        "user.store.write"
    ],
    "name": {
        "first": "test",
        "last": "test"
    },
    "country": "US",
    "clientReference": "employeeNumberString"
}