FS has supported authentication/authorization via an auth_token for a long time. Over time, there have been quite a few discussions about improvements..
Allow customized expiration - this is in 5.4
flexibility in how clients get an auth token -allowing the application to limit which users can request an auth_token would be useful
refreshing - there is no concept of getting a newer token based on an old (still valid) token. There probably should be. Lots of talk of whether the notion of refresh token is useful - this is unclear. We SORT of have this with /verify - but that does require the user to send in their passcode again.
some operations such as 2 factor auth setup, require a session to store intermediate state. Thus can't be used if the application just wants to use auth_token and no cookies (such as for mobile apps). Integrating freshness (last auth time) is in 5.5. This means us-setup now works without sessions. Need to update 2fa to send intermediate state as a token - not just in the session....
It's important to document and maintain the distinction between auth tokens and API keys - the current implementation is an auth_token - and should remain that way.
FS has supported authentication/authorization via an auth_token for a long time. Over time, there have been quite a few discussions about improvements..
It's important to document and maintain the distinction between auth tokens and API keys - the current implementation is an auth_token - and should remain that way.