Lets say you have the following curl :

curl -k \ 
-d "grant_type=password&username=Username&password=Password"  
-H "Authorization: Basic <Base64Encoded(client-id:client-secret)>"  

Now the user store and the system i.e wso2apim-gateway:8243/token will generate the result below

    "access_token": "69d21f9a-367e-3739-a18f-c29379866ef8",
    "refresh_token": "e6650f55-5b7a-33e6-99f6-b3b92008383e",
    "scope": "default",
    "token_type": "Bearer",
    "expires_in": 3600

Now I suppose subsequent request to the resource owner will embbed the access_token right ? Awesome.

But wait !!! Wireshark, Burp, Zap... OMG!!!! The access_token could easily be MITM.

So I tought to myself : "I guess the request to the resource owner will be over TLS then".

That's it ? All this OAuth gymnastic and to land to TLS. I must be missing something.

Can you help me here ? Eventually the ascess token will be sent over the network. How do you protect it ? Why not just give plain old fashion direct access to an old school user store rather than going through all this to land on TLS ?

  • 1
    What's wrong with TLS in this case? Jun 30, 2019 at 2:06
  • 2
    It is unclear what your problem is. "Why not just give plain old fashion direct access to an old school user store...." - Could it be that you miss the point what OAuth is for, i.e. provide limited third party access to some resources without the need to reveal the users password to all these third parties? Jun 30, 2019 at 4:26
  • @SteffenUllrich Maybe. It's usage is unclear in my dev team. The lead developper's architecture is like : we have a backend service - this service is offered to 3rd parties using our APIM system - 3rd parties authenticate using OAuth token we generate. 3rd partie users are not registered in our user store hence the only way they authenticate to our API is Oauth ticket. I always tought we'd had user store on our side all the time
    – tom johnes
    Jun 30, 2019 at 8:07
  • @multithr3at3d see my comment above pls
    – tom johnes
    Jun 30, 2019 at 8:07

2 Answers 2


The tokens one gets from OAuth are basically service specific passwords. These are issued in order to allow third party services limited actions in the name of the user without the need to share the users real password with these services. Given that these tokens don't allow anything more than the the users password (usually they allow less) they also don't need to be treated any better than the users password in transport, i.e. TLS is considered sufficient.


The main problem OAuth solves is the access delegation - the use case of asking the user to authorize an access to another service (without providing a password to it). OAuth achieves this by using Access Token and Refresh Token. Whereas, TLS only provides the security of data in transit.

Both Access Tokens and Refresh Tokens must be secured over transit and at rest. Access Token is usually short lived (few minutes) and is used by the service to "check" if the access is valid. The refresh token is only used to get a new access token.

At transit the security is provided by TLS. The security of the access and refresh tokens is the responsibility of the client, most likely in Memory. If the client is a web-app, these should be stored in the server side. See RFC 6819 section 5.1.6 regarding Access Token storage security.

Not the answer you're looking for? Browse other questions tagged .