HTTP Basic Authorization Request Message:
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
&client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw
Client_id : Client Account
Client_secret : Client Password
If you don`t implement TLS/SSL, your plaintext of account and password might be intercepted by Man In Middle Attack.
On the other hand, OAuth 1.0 shows that TLS is must feature to secure your plaintext but did not mention in detail what version of TLS should be adapted or who should implement it
Therefore I propose three methods outlined below to pretend your REST API.
1. Must Use SSL/TLS
You must implement the TLS/SSL before sending the plaintext of password and account to Authorization Server. By doing so, your plaintext would be less vulnerable to being intercepted.
In addition, for telecom application services, they also implement TLS to secure SIP - they set up a secure channel by TLS between the client and the server first and do HTTP Basic Digest Authentication, then start to make, answer or transfer the call in SIP over this secure channel. This is why TLS/SSL is widely used to secure communication layers in the different industry, such as game, telecom, and e-commerce.
2. Shorten the lifetime of a token key
After finishing the authorization, the client will get the access token with the lifetime. You can shorten the lifetime to reduce the risk of a token being hijacked.
3. Implement Your asymmetric encryption algorithm to encrypt plain text values of account and password
What if one day the TLS/SSL becomes not secure, the same situation will happen again that you must implement your mechanism to encrypt your plaintext of account and password.
Take RSA for example, you can implement the method as shown below.
Public and private key are generated by your server. You can give the public key to the client in private.
1. Client :
tokenUserId = encryption (useId::random key, publicKey)
tokenPassword = encryption (Password::random key, publicKey)
The client encrypts the values of userId and Password by public Key and random key and sends tokenUserId and tokenPassword to the server.
The random key could be generated by time stamp or any mechanism you prefer.
2.Server :
UserId = decryption (tokenUserId, privateKey)
Password = decryption (tokenPassword, privateKey)
The server decrypts those encrypted tokens - tokenUserId and tokenPassword - with the private key and starts to do HTTP Basic Authorization.
Of course, you can use any asymmetric encryption algorithm you like.
To conclude, the safest method to secure your important data sent over the internet is using proprietary protocol - Skype, What`s app, Line, for example, all have implemented their proprietary encryption and decryption algorithms to make the data more secure instead of following the standard. Perpahs cracking a proprietary protocol is harder than the standard one.
Reference :
RFC 5849 The OAuth 1.0 Protocol
RFC 6749 The OAuth 2.0 Authorization Framework
RFC 2617 HTTP Authentication: Basic and Digest Access Authentication
RFC 5630 The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)
