The technology behind login with social media (OpenId connect)
we have to use several applications and website for our day to day activities. but most of these applications allow to getting their service after creating the user account. so if we create accounts in everywhere, we should remember all user account credentials. it is a hard thing. also, it is a time-consuming activity. hence OpenId connect protocol helps us to sort out this problem. it allows us to use the social login feature. it means we can login into a platform by using another well-known platform.
What is OpenID Connect (OIDC)?
it is a protocol which came from OAuth protocol family. some of the people have questions like this " this protocol almost similar to OAuth then why we need this?" because OAuth only focuses on authorization but OIDC also focuses on authentication. it means OAuth shares resources to anyone who has resource access token. it is not going to check who will be received the resource. but OIDC will check if the resource will be received by the owner of that resource. so OIDC is the best option for social login.
How does OIDC work?
this protocol workflow is almost similar to OAuth because OIDC is built on top of OAuth. let's discuss the flow...
this flow will start when a user makes a request for social login to a client application. after the user requested, client app is going to ask authorization code from the authorization server by providing Client ID, Redirection Url, and scope. in OIDC there is a predefined scope called as OpenID (if we want other resources also we can add those things in scope). the authorization server will ask permission to the resource owner before to issue of an authorization code to a client application. once authorization server received the permission from the resource owner, it will give authorization code to the client app. then client app will ask access token and ID_token from authorization server by using authorizing code. then the client app will submit the authorization code to the authorization server and get access token and ID_Token(JWT). finally, client app will verify the identity of the user by using ID_Token. now we have to discuss JWT verification before that we should learn about the anatomy of JWT.
What is JWT?
it is Json web token actually it has 3 part those are header, payload, and signature. which is divided by two dots also, this token is in base64 encoding format.
SAMPLE JWT
Header
In this JSON, the value of the “typ” key specifies that the object is a JWT, and the value of the “alg” key specifies which hashing algorithm is being used to create the JWT signature component. In our example, we’re using the HMAC-SHA256 algorithm, a hashing algorithm that uses a secret key, to compute the signature.
Payload
The payload component of the JWT is the data that‘s stored inside the JWT (this data is also referred to as the “claims” of the JWT). In our example, the authentication server creates a JWT with the user information stored inside of it, specifically the user ID.
In our example, we are only putting one claim into the payload. You can put as many claims as you like. There are several different standard claims for the JWT payload, such as “iss” the issuer, “sub” the subject, and “exp” the expiration time. These fields can be useful when creating JWT, but they are optional. See the OAuth0 page on JWT for a more detailed list of JWT standard fields.
Signature
now discuss signature calculating in OIDC, there are two methods for creating a signature in OIDC. one is symmetric methods other one is asymmatric method. let's talk about symmetric signature...
What this algorithm does is base64url encodes the header and the payload created in steps 1 and 2. The algorithm then joins the resulting encoded strings together with a period (.) in between them. In our pseudo code, this joined string is assigned to data. The data string is hashed with the secret key using the hashing algorithm specified in the JWT header. The resulting hashed data is assigned to hashedData. This hashed data is then base64url encoded to produce the JWT signature. Then, applying the specified signature algorithm with the secret key on the period-joined encoded header and encoded payload, we get the hashed data needed for the signature. In our case, this means applying the HS256 algorithm, with the secret key set as the string “secret”, on the data string to get the hashedData string. After, through base64url encoding the hashedData string we get the following JWT signature:
if it uses asymmatric method to sign, #hashedData will be encryped by authorization server private key. rest of the flows are same as symmetric methods.
How token verification is happening?
in our token generation section, we are using a JWT that is signed by the HS256 algorithm where only the authentication server and the application server know the secret key. The application server receives the secret key from the authentication server when the application sets up its authentication process. Since the application knows the secret key, when the user received a JWT it can generate the signature itself. Then the application can then verify that the signature obtained from it’s own hashing operation matches the signature on the JWT itself (i.e. it matches the JWT signature created by the authentication server). If the signatures match, then that means the JWT is valid which indicates that the API call is coming from an authentic source. Otherwise, if the signatures don’t match, then it means that the received JWT is invalid, which may be an indicator of a potential attack on the application. So by verifying the JWT, the application adds a layer of trust between itself and the user.
Why need signature verification?
if OIDC does not have token verification, it is vulnerable to man in the middle attack. because during the network transmission of JWT, anyone can intercept the transmission and change the payload value as they wish. so if an attacker replaces others information on his information, he can able to log in to others user accounts. hence it leads forgery. signature verification is preventing this kind of forgery attacks.
Comments
Post a Comment