HTTPS versus Token Auth

Continuing the discussion from REST API Token authentication - How to set this up?:
I drug this out of my dusty collection of partial whitepapers and polished it up a bit. A we go forward with more Token based authentication and integration’s in E10 specifically and Epicor and partners in general, I thought it is relevant.

HTTPS != Token Authentication
I participate in conversations and threads all the time where folks get these confused. With the evolution’s made in E10 in the past couple of years and the roadmap ahead, I just wanted to clarify some confusion. I’m not making a doctoral thesis here but a quick overview so forgive some simplifications as I try to do an intro.

These are all about encrypted what’s on the wire. The client and server agree on mechanism to encrypt traffic between them and voila, no clear text on the wire you can sniff with something like wire shark.

Often Https is confused or commingled in conversation with SSL and TLS. SSL and TLS are what is actually doing the encryption. Https coordinates between the client and server to determine which encryption approach to use (SSL, TLS and the different versions). I sometime make the analogy that Https is an umbrella protocol that different encryption approaches such as SSL or TLS sit under.

For E10, it also supports ‘Windows’ for network encryption as a WCF protocol. In that binding, a client and server on the same Active Directory Domain perform a similar coordination (Windows Stream Security) to arrive at an encryption approach and prevent clear text as well. Check out the help topic on ‘Network Protocol Bindings’ for more information. It’s a good read.

Token Authentication
So now that you have a secure way to chat on the internet or in your facility, now how do you know who is talking? That’s where token authentication comes in. Historically, we all are used to typing in names and passwords and the server trusts the client- Voila – user is found and a call continues. Unfortunately, life is not so simple anymore. There are numerous servers used to provide a feature. Integrations are done to weave together systems. Storing a user’s password in many systems is not practical to keep in sync and a horrible security nightmare.

Instead, what is commonly done is to use a Token Provider to centralize a user’s IDENTITY in a single service and database behind it. A successful authentication against the Token Provider gives the caller a token to prove who they are – kind of like a passport or driver’s license in the real world. Just like a passport, you don’t want to lose the token so they are kept private and secure. These tokens can be used to then verify a user’s identity to any server that accepts them. The name ‘bearer token’ meaning anyone bearing the token can act on behalf of the user. This allows for the passing of identity across services.

FYI - ERP 10 and it’s Token Provider secure the users password with a one way hash. That means no clear text password lying around anywhere. To validate the password, the password sent by a client is also one way hashed to see if there is a match. This one way hash has several steps to ensure it stays ahead of exploit approaches.

The token result is a blob of text with a bunch of attributes bundled up into a ‘bearer token’ that can look something like this:

While unreadable by humans, it’s easily decoded into a json blob describing the user that authenticated against the Token Provider:
{ “typ”: “JWT”, “alg”: “RS256”, “x5t”: “x478xyOplsM1H7NXk7Sx17x1upc”, “kid”: “x478xyOplsM1H7NXk7Sx17x1upc” }.{ “aud”: “00000002-0000-0000-c000-000000000000”, “iss”: “”, “iat”: 1513894813, “nbf”: 1513894813, “exp”: 1513895713, “acr”: “1”, “aio”: “ATQAy/8GAAAAHmcxxS33wAa4lKue//DfsYChsyIj/DPH7ViWFpTnjfrKFzFdSqJdOXGBqVJo57bF”, “altsecid”: “5::10033FFF8CF03720”, “amr”: [ “wia” ], “appid”: “d807e3ed-10b5-4caa-b2ec-00a7caf0b6b7”, “appidacr”: “0”, “e_exp”: 259800, “email”: “”, “idp”: “”, “ipaddr”: “”, “name”: “belia”, “oid”: “502e21fc-a61e-406b-9b0b-44b1a1a4591c”, “puid”: “10037FFEA68D265F”, “scp”: “User.Read”, “sub”: “DoOC9AQweKlABO6EvexRhwWAjBLEYu4VVjDL0fAqmvc”, “tenant_region_scope”: “NA”, “tid”: “8c8e5b43-7e3c-42f2-8281-3a9cbc8febd6”, “unique_name”: “”, “uti”: “4UbSY0ZXdUuvMJ1lM-IyAA”, “ver”: “1.0” }.[Signature]

There are a variety of formats of these tokens. The commonality is they contain ‘claims’ – the properties in the token such as “email”: “” and “iss”: “”. The two previous claims could be combined to authenticate and identity a user in the server. The server trusts tokens from the issuer (“iss”). The server can map from the claim to their internal user through a variety of claims such as email, name or even just the id of the token.

This usage of a ‘three way trust’ is similar to how Windows works. A client logs into an Active Directory Domain and receives a token. The client presents the token to a domain server which trusts the Active Directory Domain Controller so accepts the clients token. Only AD contains the user’s password. The benefit with the bearer token approach is that any type of language and computer can participate in the trust.

A couple of closing notes on bearer tokens – they usually have an expiration date (“exp”: 1513895713) which provides a time window for how long the token is valid before a client needs to retrieve a token again. That’s configured at the Token Provider. Tokens can also be targeted for a particular service (“aud”: “00000002-0000-0000-c000-000000000000”). If a token is passed onto a different service, that next service would have to trust the first service or other means to allow for reuse of the token and establish a ‘chain of trust’.

Authentication != Authorization
One note with everything above is that all this bearer token effort to eliminate a ‘clear text password’ and promote reuse of identity is that we are just discussing how to IDENTIFY the user. What they are allowed to do in a particular app or service is still the responsibility of the service that consumes the token. In ERP 10 for example, the token is provided to a service and the service maps to a User. When the token is provided to Epicor Data Discovery, EDD does the same – mapping then token to a user in its user db.

I came across an analogy a while back to real life which I love. A Driver’s License identifies you and contains claims about you – your height, date of birth, etc. It does not authorize you to drink. You present your ‘bearer token’ with ‘claims’ at a bar and you are authorized to purchase alcohol if your age is greater than what is allowed. Age requirements vary around the country and the world. The claim is your birthdate, how you are authorized, varies by the ‘service’.

I hope this helps position what e10 is doing and what the heck I am talking about sometimes…