Using rails secret to salt authentication keys in devise -

i creating ember app has devise worked in authentication. i'm getting stuck how these different tokens come play.

i'm reimplementing deprecated :token_authenticatable devise "strategy" using method described here. i'd add token authentication api , sign requests user's token.

what i'm wondering is, though it's using devise.secure_compare thwart timing attacks, it's still storing authentication_token in plain text, if gain access database, tokens potentially used steal session, no?

devise seems use 2 different types of "tokens" in modules:

1. creating token devise.friendly_token , storing plain text. doing token (as used in :rememberable).
2. creating salted token devise.token_generator (as seem in :confirmable).

the second method looks me token salted using devise.secret_key derived rails secret in config/secrets.yml. way token encrypted , if database exposed reason, tokens couldn't used, right? equivalent of having private key (rails secret) , public key (authentication_token).

i have quite few concerns:

• should use devise.token_generator create authentication_tokens?
• what word on security these type of tokens?
• how csrf token factor devise?

devise lot of things, , not things particular application needs or in way applications needs. found wasn't fit application. lack of support/removal of api token authentication provided enough motivation move on , implement needed. able implement token auth scratch easily. gained full flexibility managing user signup/workflows/invitations , on without constraints , contortions required of devise. still use warden devise uses rack middleware integration.

i've provided example of implementing token authentication/authorisation on another stackoverflow question. should able use code starting point token authentication, , implement additional token protection require. i'm using oauth token approach ember.js.

also consider if encrypting tokens hand-waving because depending on deployment environment , how manage master key/secret, may giving false sense of security. remember encryption says nothing integrity/validity of token or related authentication/authorisation information, unless have mac/signature encompasses used in access decision. whilst may go trouble of protecting tokens attackers whom have access database, may trivial same attackers inject bogus tokens or elevate privileges existing users in database, or steal or modify real data may want achieve!

i've made large comments in respect of providing integrity , confidentiality controls authentication/authorisation information (which tokens part of) on doorkeeper gem. suggest reading full issue idea of scope of problem , things consider because none of gems should done. i've provided overview on how avoid storing tokens on server altogether , i've provided sample token generation , authentication code in gist deals timing based attacks.