what is authToken

HI,
I have several times heard of this term authToken. Its probably used when making a login form so as
to securely pass the info and identify both parties. Please shed some more light on it or provide some reference.

How is it implemented and what are its uses exactly ?

Thanks
Rohit BajajAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

btanExec ConsultantCommented:
To simplify and help understanding, I see AuthToken as Password which is mapped to an identity (usually your userid to take it simple). The use of it is when you as the user needs authenticated prior to access and subsequent on success check (again) for the user rights authorised to use the resources...

Of course the AuthToken can be further set to contain more than just a password, such as in the form of hash of your Username appended by Email ID and Password - using this hash key to pass to resource provider to identify yourself so as to grant use for certain resource. The latter is usually API in programming context like to use any Google API or Cloud API open to software to call requires certain AuthToken to be presented before the use is allowed.

As a whole, such AuthToken is user-specific and is a permanent token. It become invalid once user's account is deactivated. So it is (normally) recommended to note down your Authentication Token. You need to manage all the active secret auth tokens of your account diligently to the various resource service provider .

..some provider provides more info too..
https://www.twilio.com/help/faq/twilio-basics/what-is-the-auth-token-and-how-can-i-change-it
https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_class_Auth_AuthToken.htm
http://answers.livefyre.com/developers/getting-started/tokens/auth/

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
BigRatCommented:
More specifically it refers to the type of authentication now in common practice, whereby one logs into a site using the identity and password of another site. Often one sees "Login via Twitter", Facebook , Instagram or Google. When a site provides such a facility you get redirected to the other site, called the provider, where you log in and the site sends an "auithToken" in the form of a JSON Web Token (JWT see http://http://jwt.io and RFC 7519). The third part of the token can only be decoded (and thereby validated) using a special key which you have sent to the provider when you registered for this service.

This token is sent to the server in the HTTP header and so, unlike a cookie, can be sent to any URL. Thus if your "web site" consists of many URLs, like ordering, customer service etc., you can use the same token, where as a cookie is valid only for one domain. This type of authentication is commonly done outside the database, whic allows horizontal scaling. Best case - you don't need to store customer passwords and address data permanently, since you can get it from the provider. Second best, you don't need to store passwords and you get to preload address data into ordering forms and/or check that somebody is ordering from a validated address.
btanExec ConsultantCommented:
Indeed - this is all about token authentication with the gist as follows:
-User Requests Access with Username / Password
-Application validates credentials
-Application provides a signed token to the client
-Client stores that token and sends it along with every request
-Server verifies token and responds with data
Every single request will require the token.
The token should be sent in the HTTP header so that we keep with the idea of stateless HTTP requests.
You may be interested to see an infographic too https://cask.scotch.io/2014/11/tokens-new.png
Determine the Perfect Price for Your IT Services

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden with our free interactive tool and use it to determine the right price for your IT services. Download your free eBook now!

Rohit BajajAuthor Commented:
HI,
Few more things i want to clarify :
1)  -Client stores that token and sends it along with every request
Where does the client stores the token ? Is it in a cookie ?

2)  -Server verifies token and responds with data
So does the server maintains another table for authtoken along with username and password

3)  The token should be sent in the HTTP header so that we keep with the idea of stateless HTTP requests.
what if i store the token in a cookie and then automatically it will be sent to the server with each request.
Why to send it in HTTP header ?

Thanks for insights :)
BigRatCommented:
1) The client must store the token in local storage (see http://stackoverflow.com/questions/18247130/how-to-store-the-data-to-local-storage
or http://ngmodules.org/modules/ngStorage)

2) A server (note A and not THE) only needs the secret which was used to encode the token. A server extracts the token from the header and uses the secret to decode and thereby validate the token. If it decodes correctly the data in the payload part will be enough for accessing the data. It is not necessary to keep extra tables. The point about "A" server is that you can replicate your servers for performance.

3) A cookie is only sent to the domain which issused it. In a corporate setup you might have different databases and/or services on different machines possibly with different domains (for example data in America and also in Japan). A Auth Token is sent to a machine which can decode it. Furthermore cookies don't need to be honored by browsers, and indeed, a browser or a proxy may in fact truncate them. An authorization header is always honored by middleware.

There are a fair number of tutorials regarding authentication tokens on the web, both with AngularJs and JQuery. Here are two :

https://thinkster.io/angularjs-jwt-auth
http://www.toptal.com/web/cookie-free-authentication-with-json-web-tokens-an-example-in-laravel-and-angularjs
btanExec ConsultantCommented:
cookie is not a token, the former is for used by browser in case like tracking session. you can store token in cookie but not recommended.

Cookie is like a session id embedded in http header once user get authenticated. That id can be stored in a cookie) and attaches in every subsequent client outgoing request. Quite like a "token" since it act like a set of credentials. But it just a string identifier which server use this for tracking session state - hence stateful.

Token is no stateful like cookie. However, credentials are still exchanged for a token (based on the configuration of the fields inside it) which is then attached to every subsequent client request. Token can also be stored in a cookie.

The backend server will be configure to recognized what is request to be inside the token and use that to check against central store like for the user id and password e.g. assuming the setting for the token = user_id|expiry_date|HMAC(user_id|expiry_date, k) where "k" is secret and likely user password...the token can be string as well...

HTTP header is just a carrier for the cookie (carrying the token)  or even the HTTP body with the Token content itself only without cookie...such HTTP header authentication indirectly is to save storage of token which is generated on fly for authentication but once it is done it can still be retained as part of cookie ...really depends on implementation scheme. Possible disadvantages of using cookie as a whole has poor scalability (especially over more than one server farm) and extensive memory usage since it needs to maintain session state....
BigRatCommented:
btan: "Cookie is like a session id embedded in http header" and "Token is no stateful like cookie."

False. A session id is issued from a server such that on return via a request it identifies the user, whether authenticated or not. Session ids can be embedded in the URL or given in a cookie. Normally cookies do not contain state information since this can be falsified, so in effect they are stateless.

A token is issued by an authorisation entity and hence is stateful - it contains the fact that the authentication has taken place. An entity accepting a token, like a server, only needs to know a secret which it has shared with the authorisation  agency. It uses this secret to check the token and if the check passes the payload contains (or should contain) all that is necessary for the operation to be carried out. There is no need for further tables of users and passwords.

See: http://code.tutsplus.com/tutorials/token-based-authentication-with-angularjs-nodejs--cms-22543
btanExec ConsultantCommented:
Sure I understand - I am referring in general and not specific to certain implementation. The GET URl string can have the session id as mentioned. For some that I seen cookie can contain more identifier to "remember" not necessarily session but the user personalised info.
Token is issued on authentication like SAML token etc which can be part of the transaction when establishing the id checks rather similar to kerberos ticket.
Stateless (a.k.a. Server side scalability): there is no need to keep a session store, the token is a self-contanined entity that conveys all the user information. The rest of the state lives in cookies or local storage on the client side.
https://docs.google.com/drawings/d/1wtiF_UK2e4sZVorvfBUZh2UCaZq9sTCGoaDojSdwp7I/edit
btanExec ConsultantCommented:
Just to add on this
 Application-defined personal information may be contained in this cookie, depending on the claims that an administrator includes in the token, and this personal information may be written to the disk of the Web browser. The contents of authentication cookies are signed, but they are not encrypted when they are written to disk.
All authentication cookies are session cookies that typically exist only in memory. These cookies are removed when the browser session ends or the ADFS sign-out procedure is invoked.
https://technet.microsoft.com/pt-pt/library/cc773244(v=ws.10).aspx
The enhanced identity privacy explanation may be useful too.
Rohit BajajAuthor Commented:
HI,
I didnt get time to read the last two posts.. will get back... if any questions..
By the way... this was an awesome discussion.

Thanks
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Java

From novice to tech pro — start learning today.