Learning Security Day 1
It is not a good idea to send user credentials as plain text in the request body as
(1) Increased risk of being leaked
(2) Storing credentials along side application data exposes them to any injection vulnerabilities introduced by development team
(3) It also does n't scale very well as the number of applications grows, as each application would require its own often duplicated code. The security updates to different vulnerability fixes becomes difficult.
Single Sign On (SSO)
Here the user authenticates once with an identity provider then gets the keys to access all the applications, they are authorized for.
If the user already has an account with a third party like google, how can ur application and google trust each other to allow an authenticated entity in google to access our application
By this the customer does n't have to go through the registration process. Oauth2, openId connect are standards that are used to accomplish this.
Basic Authentication
After authenticating with credentials with the identity provider is performed, an identifier like a GUID is returned.The identifier is a reference to a state in the identity server.
If the token gets leaked it could be just the password
Tokens are send in the request header.
Opaque Tokens - By reference
It is a reference to a resource
By Value Token - This will include the state information like username, email, what the bearer of the token is authorized for and expiry time. This eliminate the need for calling the identity provider.
These tokens are generally signed by the identity provider. Hence services can use the public key of the provider to ensure it is valid and hasn't been tampered with.
Encryption is used in token.
JWT (Json Web Token) is base 64 encoded token. It can be transmitted in the header or url but beware of the restrictions on the number of characters that can be transmitted over the url.
JSON Web token has 3 parts separated by dots. It consists of
Header (json object)
Payload (json object)
Signature
Header contains the type of token and the algorithm that is used to sign the token. The common algorithms used are RSA, HMAC or SHA256.
If you don't define a algorithm it would be SHA256 by default.
Any information can be put on th payload, we can also add additional information known as claims which is optional such as the expiration time (exp), subject (sub), or issuer (iss).
Don't include sensitive information in the payload as it can be easily de-coded.
Encode the header and payload in base 64 then we append the secret and then we apply the algorithm to sign our certificate.
Signature which is the sum of the encoded header, the encoded payload, a secret, and lastly the algorithm which is specified in the header.
The header and payload can easily be decoded, but not the signature. The reason why is because it checks two things; first verify the header and payload has not been altered, and secondly check the private key is valid to make sure the sender is who it is.
THere is a secret which is a string with which the token gets hashed.
In short, if either the header, payload or private key changes along the way, the verification process will fail thus the token is not equal to the one that was initially created.
http://jwt.io
Oath2
This is an open standard to protect a resource known as "protected resource"
It is a resource owner giving a third party access to a protected resource.It is for delegated authorization.
Different actors
Passenger is the client - The entity that wanted to access the protected resource which is train.
The train station is known as the resource server. An entity capable of authorizing access to a protected resource. In order to get through the train station gates the passenger needs a valid ticket, which is the token.
Token can be byValue (printed ticket) or byReference (eticket) where the details of the ticket are stored on a server which needs to be looked up.
In order to validate the ticket it needs to be scanned by a machine or validated by a ticket examiner which is the authorization server. The train company is the resource owner
Most popular Auth2 grant type is Authorization code grant
In Auth2 the term grant type refers to the way an application gets an access token.
For more info refer https://developer.okta.com/blog/2018/04/10/oauth-authorization-code-grant-type
At the high level the flow is as below
OpenID Connect
One of the key features of OpenID Connect is the identity token.
It is not a good idea to send user credentials as plain text in the request body as
(1) Increased risk of being leaked
(2) Storing credentials along side application data exposes them to any injection vulnerabilities introduced by development team
(3) It also does n't scale very well as the number of applications grows, as each application would require its own often duplicated code. The security updates to different vulnerability fixes becomes difficult.
Single Sign On (SSO)
Here the user authenticates once with an identity provider then gets the keys to access all the applications, they are authorized for.
If the user already has an account with a third party like google, how can ur application and google trust each other to allow an authenticated entity in google to access our application
By this the customer does n't have to go through the registration process. Oauth2, openId connect are standards that are used to accomplish this.
Basic Authentication
After authenticating with credentials with the identity provider is performed, an identifier like a GUID is returned.The identifier is a reference to a state in the identity server.
If the token gets leaked it could be just the password
Tokens are send in the request header.
Opaque Tokens - By reference
It is a reference to a resource
By Value Token - This will include the state information like username, email, what the bearer of the token is authorized for and expiry time. This eliminate the need for calling the identity provider.
These tokens are generally signed by the identity provider. Hence services can use the public key of the provider to ensure it is valid and hasn't been tampered with.
Encryption is used in token.
JWT (Json Web Token) is base 64 encoded token. It can be transmitted in the header or url but beware of the restrictions on the number of characters that can be transmitted over the url.
JSON Web token has 3 parts separated by dots. It consists of
Header (json object)
Payload (json object)
Signature
Header contains the type of token and the algorithm that is used to sign the token. The common algorithms used are RSA, HMAC or SHA256.
If you don't define a algorithm it would be SHA256 by default.
Any information can be put on th payload, we can also add additional information known as claims which is optional such as the expiration time (exp), subject (sub), or issuer (iss).
Don't include sensitive information in the payload as it can be easily de-coded.
Encode the header and payload in base 64 then we append the secret and then we apply the algorithm to sign our certificate.
Signature which is the sum of the encoded header, the encoded payload, a secret, and lastly the algorithm which is specified in the header.
The header and payload can easily be decoded, but not the signature. The reason why is because it checks two things; first verify the header and payload has not been altered, and secondly check the private key is valid to make sure the sender is who it is.
THere is a secret which is a string with which the token gets hashed.
In short, if either the header, payload or private key changes along the way, the verification process will fail thus the token is not equal to the one that was initially created.
http://jwt.io
Oath2
This is an open standard to protect a resource known as "protected resource"
It is a resource owner giving a third party access to a protected resource.It is for delegated authorization.
Different actors
Passenger is the client - The entity that wanted to access the protected resource which is train.
The train station is known as the resource server. An entity capable of authorizing access to a protected resource. In order to get through the train station gates the passenger needs a valid ticket, which is the token.
Token can be byValue (printed ticket) or byReference (eticket) where the details of the ticket are stored on a server which needs to be looked up.
In order to validate the ticket it needs to be scanned by a machine or validated by a ticket examiner which is the authorization server. The train company is the resource owner
Most popular Auth2 grant type is Authorization code grant
In Auth2 the term grant type refers to the way an application gets an access token.
For more info refer https://developer.okta.com/blog/2018/04/10/oauth-authorization-code-grant-type
At the high level the flow is as below
- The application opens a browser to send the user to the OAuth server
- The user sees the authorization prompt and approves the app’s request
- The user is redirected back to the application with an authorization code in the query string
- The application exchanges the authorization code for an access token
Get User's permission
https://authorization-server.com/auth
?response_type=code
&client_id=29352915982374239857
&redirect_uri=https%3A%2F%2Fexample-app.com%2Fcallback
&scope=create+delete
&state=xcoiv98y2kd22vusuye3kch
Here’s each query parameter explained:
response_type=code- This tells the authorization server that the application is initiating the authorization code flow.client_id- The public identifier for the application, obtained when the developer first registered the application.redirect_uri- Tells the authorization server where to send the user back to after they approve the request.scope- One or more space-separated strings indicating which permissions the application is requesting. The specific OAuth API you’re using will define the scopes that it supports.state- The application generates a random string and includes it in the request. It should then check that the same value is returned after the user authorizes the app. This is used to prevent CSRF attacks.
If the user approves the request, the authorization server will redirect the browser back to the
redirect_uri specified by the application, adding a code and state to the query string.
For example, the user will be redirected back to a URL such as
https://example-app.com/redirect
?code=g0ZGZmNjVmOWIjNTk2NTk4ZTYyZGI3
&state=xcoiv98y2kd22vusuye3kch
The
state value will be the same value that the application initially set in the request. The application is expected to check that the state in the redirect matches the state it originally set. This protects against CSRF and other related attacks.
The
code is the authorization code generated by the authorization server. This code is relatively short-lived, typically lasting between 1 to 10 minutes depending on the OAuth service.
Exchange Auth code for Access Token
Now that the application has the authorization code, it can use that to get an access token.
The application makes a POST request to the service’s token endpoint with the following parameters:
grant_type=authorization_code- This tells the token endpoint that the application is using the Authorization Code grant type.code- The application includes the authorization code it was given in the redirect.redirect_uri- The same redirect URI that was used when requesting the code. Some APIs don’t require this parameter, so you’ll need to double check the documentation of the particular API you’re accessing.client_id- The application’s client ID.client_secret- The application’s client secret. This ensures that the request to get the access token is made only from the application, and not from a potential attacker that may have intercepted the authorization code.
The token endpoint will verify all the parameters in the request, ensuring the code hasn’t expired and that the client ID and secret match. If everything checks out, it will generate an access token and return it in the response!
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"MTQ0NjJkZmQ5OTM2NDE1ZTZjNGZmZjI3",
"token_type":"bearer",
"expires_in":3600,
"refresh_token":"IwOGYzYTlmM2YxOTQ5MGE3YmNmMDFkNTVk",
"scope":"create delete"
}
The Authorization Code flow is complete! The application now has an access token it can use when making API requests.
OpenID Connect
One of the key features of OpenID Connect is the identity token.
No comments:
Post a Comment