Pan Chuan
2016.12.08
- HTTP Basic Auth
- HTTP Digest Auth
- Cookie-based Auth
- Token-based Auth ( JWT )
- OAuth2
Authentication answer the questions:
Authorization answer the questions:
Authentication
Authorization
Enter a building with badge/fingerprint/retina scan
Login into a forum with username and password
allow to enter a door
Edit yourself's thread
Edit other people's thread
Authentication always proceeds Authorization.
We have paradigm for Authenentication, but no common rules for Authorization. Authorization highly depends on your business logic.
https://books.rakuten.co.jp/mypage/delivery/receiptPrint?order_number=213310-20160914-0910455279&back_number=2f4c0b5b26845f788d71377383113a26efdd61b68fd5595771663b066a35a02c&shippingId=82719971&customerName=Pan%E3%80%80Chuan
82719981 can work.
receipt page url:
receipt page pdf:
You have access to see everyone's receipt..
Stateless REST APIs
Client
DELETE http://myapis.com/v1/res/456
userid="111"
Need check again if userid '111' can really delete resource 456 by querying DB/ACL.
123
789
GET /someresource/ HTTP/1.1
Host: www.hostname.com
Authorization: Basic aHR0cHdhdGNoOmY=
Base64(<username>:<password>)
client
server
init request
401 return, nonce
send[ username,nonce,MD5(nonce,username,URI,Method,password)]
200
1) look up password from DB
2) re-compute MD5 and compare
real Http Digest is more complex than this simple version diagram, please check the wikipedia
Cookie-based Auth is stateful.
Backend servers need to share/sync all sessions if multiple service instance are running.
The server needs to keep track of active sessions in a storage(Framework context/DB/Redis).
Same Step 1 as Cookied-based
token = user_id | expiry_date | HMAC (user_id | expiry_date, secret)
token = AES(user_id | expiry_date, key)
token = RSA(user_id | expiry_date, private_key)
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
{
"typ": "JWT",
"alg": "HS256"
}
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
Header Json:
Payload Json:
Signature: HMACSHS256(base64(header) + "." + base64(payload),"secret")
Payload: base64(payload)
Header: base64(header Json)
- backend does not need to track tokens, each token is self-contained
- save sessions' storage
- decoding jwt is faster than lookup DB/Cache for session query.
- Native mobile platforms doest mix well with cookie,
- cross domain headache is gone.
- Sharing the Jwt between different applications.
- Eg: to obscure URL parameters or POST body.
https://your.awesome-app.com/make-friend/?from_user=B&target_user=A
https://your.awesome-app.com/make-friend/?jwt=aaa.bbb.ccc
{
“expire”:1441594772,
"sub": "B@example.com",
"aud": "www.example.com",
"from_user":"B",
"target_user":"A"
}
jwt payload part:
Not Good,
Need login first
Good,
One Click
the jwt token is valid forever unless the signing key is changed or expration explicitly set.
payload text is just base64 encoded.
the signing key should be treated like any other credentials and revealed only to services that absolutely need it.
- simple but not secure
- secure but usage is limited
- flexible/powerful but resource cost
- balanced and widely scenario support
Resource Owner: the person or the application that holds the data to be shared.
Resource Server: the application that holds the protected resources.
Authorization Server: the application that verifies the identity of the users.
Client: the application that makes request to the Resource Server on behalf of the Resource Owner.
rfc 6749:
Resource Owner
Authorization Server
Resource Server
Client
I want to see a list of photoes
Resource Owner
Authorization Server
Resource Server
Client
Hi, RS, could you give me a list of photoes?
Resource Owner
Authorization Server
Resource Server
Client
Sorry, this is a protected resource, You
need an access token.
Resource Owner
Authorization Server
Resource Server
Client
Hi AS, can I get an access
token? RS is asking.
Resource Owner
Authorization Server
Resource Server
Client
Sure, But I need to ask some
details to the user first.
Resource Owner
Authorization Server
Resource Server
Client
Hi, Could you provide your credentials?
I need to verify your identity
Resource Owner
Authorization Server
Resource Server
Client
No problem, I am snow@gmail.com and my
password is secret
Resource Owner
Authorization Server
Resource Server
Client
The user is who claims to be,
Here is your access token: yGH38dee0oHN72Dyen3
Resource Owner
Authorization Server
Resource Server
Client
Hi Backend,
Here is my token: yGH38dee0oHN72Dyen3
Resource Owner
Authorization Server
Resource Server
Client
Hi I have been give token: yGH38dee0oHN72Dyen3
can you tell me who it belongs to?
Resource Owner
Authorization Server
Resource Server
Client
Of course, the token is valid and it belongs to:
snow@gmail.com
Resource Owner
Authorization Server
Resource Server
Client
Everything is allright, This is the
list of photoes,enjoy!
Resource Owner
Authorization Server
Resource Server
Client
Here you are the list of photoes, enjoy!
Resource Owner
Client
OAuth2 works as a delegation way, as the Client has no idea about the credentials of the Resouce Owner
OrderAPI
ItemAPI
ShopAPI
GoAuth
rmsX microservices:
Some Client
1.apply key
2.request with key
3.validate key
Authorization: serviceId Key:Signature
Date: 2016-12-11T15:03:24Z
Requst Header:
Requst Header:
Authorization: serviceId Key
Signature = Base64(HAMC-SHA1(APISecret, StringToSign))
StringToSign = Date + " \t" + ReqURI + "\t"+ ReqMethod
{
"StatusCode": 200,
"Message": "Validate successfully.",
"Metadata": {
"RoleName":"General Engineer",
"UserName":"chuan.pan@rakuten.com",
"ResourcePermission":[
{"Resource":"order/find", "Methods":["GET"]},
{"Resource":"order/get", "Methods":["GET"]},
{"Resource":"order-detail/add", "Methods":["POST"]},
]
}
}
- Http Basic Authentication
- Http Digest Authentication
- Cookie-based VS Token-based Authentication
- Oauth2 VS Jwt