Decades before we had a way to authenticate the users in order to access the data that is present on the website. How it was done there ? through a simple username and password which is stored in the database in a relational format with password being hashed. In modern applications we have a bunch of these things done by external 3rd party authentications like Google Sign In or Microsoft Sign or Sign In with GitHub and much more so eliminating the use of password changes the whole bunch of security vulnerabilities that are present and all the apps have gone to a micro level having API’s and things not handled by the organization itself so sending user credentials to those seems to be a issue of trust.
Let’s now understand the current process of authentication in terms of a physical example . User A goes to the motel registers for a room stay 3 days then that user needs to provide some information to them like the phone number, email address, first name, last name which are PII and things like their account details for checking the amount of transaction be successful which is SPII so we authenticate ourselves what we have .
Claims Based Authentication
Claims-based identity is a common way for applications to acquire the identity information they need about users inside their organization, in other organizations, and on the Internet.
The below image depicts the typical version of the authentication process but let’s try to understand this in a more real time example way so we go to a bank and try to take a loan then in that case we would be needing certain verification documents to be submitted so one fundamental question is that how do we think that the document is reliable and legitimate so in this case since the government is providing those identities with your details (claims) is something that is reliable and that document is considered as Identity and Security Token which is published by the government itself in other terms it is (Secure Token Service (STS)) and they provide the token indirectly verifying you are a right person and the process proceeds ON
Claims Based Authentication is about defining who you trust to give you accurate information about identity, and only ever using that information provided.
Terminologies
- Identity Provider — Trusted User , Issuing Authority , Authorization Server (AS) , Open ID Provider or Asserting Party
- User — Resource Owner or Subject
- Relying Party — Service Provider or Client
Tokens vs Passwords
User A -> Shares Password -> Relying Party -> Gives the Password -> Identity Provider
Let’s analyze the vulnerability in this case we have the user’s password is shared all across the network and we can eavesdrop and get it
On the case of Reference Tokens
User A -> Shares Password -> Identity Provider -> Reference Token -> Relying Party -> Identity Provider -> Identity and Claims
In the case of Self contained Tokens
User A -> Shares Password -> Identity Provider -> Identity and Claims -> Identity Provider -> Validate the token
Tokens come in with different format one is SAML — Oasis Security Assertion Markup Language uses XML based framework for describing and exchanging security information between on-line business partners. This is expressed in the form of portable SAML assertions that applications working across security boundaries that can be trusted.
In this the SAML is encoded with base 64 and we have the authentication request then the signatures attached to it and more to the fact it is very standardized.
As you could see in the SAML we have the payload that is long and packed with things JWT tokens are a compact versions where the data is passed as a JSON object and here is the sample of a JWT which would have 3 parts of it we have Header , Payload and a combination of Both which is called as Signature all encoded on hashing algorithm
Federation
Federation enables the access of services across organizational or domain boundaries by establishing trust relationships between the respective domain’s identity provider. With federation, there’s no need for a user to maintain a different username and password when accessing resources in other domains.
The simplified way to think about this federation scenario is as follows:
- The website, in domain A, uses the authentication services of Identity Provider A (IdP-A).
- The user, in domain B, authenticates with Identity Provider B (IdP-B).
- IdP-A has a trust relationship configured with IdP-B.
- When the user, who wants to access the website, provides his/her credentials to the website, the website trusts the user and allows access. This access is allowed because of the trust that is already established between the two identity providers.
With federation, trust isn’t always bidirectional. Although IdP-A may trust IdP-B and allow the user in domain B to access the website in domain A, the opposite isn’t true, unless that trust relationship is configured.
A common example of federation in practice is when a user logs in to a third-party site with their social media account, such as Twitter. In this scenario, Twitter is an identity provider, and the third-party site might be using a different identity provider, such as Azure AD. There’s a trust relationship between Azure AD and Twitter.
Oauth 2.0
https://sts.cloudready.ms/adfs/oauth2/authorize?response_type=code&client_id=<something>&redirect_uri=<something>
Unlike SAML or WS-Federation this doesn’t consume much of a URL space or a long text instead it is more concise and here we have the type of the response and which link to redirect for the user and the client id is the relying party id. Talking about a possible vulnerability which many of the websites have is if the redirect URL is not properly handled then I as a hacker can give any URL so it’s important to whitelist the permutations and combinations
Open ID Connect
- Simple has both Authentication and Authorization Protocol
- Extension of OAuth2
- JWT is the token type used
- Supports multiple relying party
- Encryption , discovery , dynamic client registration and session management
Relying Parties
- Registration this is important because the JWT needs to have the public cryptographic key so that it can validate the token and also it needs to know bunch of URL’s on when to connect how to connect and contact the Identity Provider and from the Identity Provider side also they need to confront it as trusted source so that it doesn’t block the particular request
- Workflow it is simple all it has do is construct and get the response back from the Open ID connect server and verify digital signature , timestamp and lifetime to make sure it is not expired and this is identified by Client Id (Relying Party) which again boils down to two more confidential and public relying parties so confidential means something that is more of running on the server whereas public relying parties is Javascript on browser or mobile apps
- Metadata (source: https://swagger.io/docs/specification/authentication/openid-connect-discovery/) the need for this is that as discussed above we need to provide the content to the Identity Provider so it has info about issuer , the signing certificate public key along with supported scopes , claim types , token types etc.
Scopes
OpenID Connect (OIDC) scopes are used by an application during authentication to authorize access to a user’s details, like name and picture. Each scope returns a set of user attributes, which are called claims. The scopes an application should request depend on which user attributes the application needs. The standard scopes are profile , email , address , phone and offline access which can make the token refreshed if it is expired or invalid .
- id_token this is basically the token for the user’s identity
- access_token level of access that is being generated on behalf of the user or the client
- refresh_token new access token is generated if the token becomes invalid or expired
- code authorization code a short lived code that is exchanged for other tokens in special scenarios
A typical example is like we would be signing into let’s say Medium and we have google sign in option and it will ask Medium will read the following and it will have a consent option and it is up to the user to grant the permission or not.
JWT Payload
{ “sub” : “alice”, “iss” : “https://openid.c2id.com", “aud” : “client-12345”, “nonce” : “n-0S6_WzA2Mj”, “auth_time” : 1311280969, “acr” : “https://load.c2id.com/high", “iat” : 1311280970, “exp” : 1311281970 }
The above is a typical payload of the Open ID connect where fields like the subject , issuer , generated for a particular audience (aud) , issued at and expiration time are required fields and all others are optional fields along with custom parameters which one can have based on the security measures
Endpoints
- Authorization Endpoint — This is the endpoint where the users would be routed to log in and we would be having a UI component where they can enter the credentials . Based on the flow chosen it will return a code or id_token or refresh token . Relying party to the identity provider the code would look something like this
GET /authorize?
response_type=code
&scope=openid%20profile%20email
&client_id=s6BhdRkqt3
&state=af0ifjsldkj
&nonce=n-0S6_WzA2Mj
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
Host: server.example.com
HTTP/1.1 302 Found
Location: https://openid.c2id.com/login?
response_type=code
&scope=openid
&client_id=s6BhdRkqt3
&state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb- UserInfo Endpoint — It retrieves information about the end user and the claims which they have approved
HTTP/1.1 200 OK Content-Type: application/json
{ "sub" : "83692",
"name" : "Alice Adams",
"given_name" : "Alice",
"family_name" : "Adams",
"email" : "alice@example.com",
"picture" : "https://example.com/83692/photo.jpg"
}
HTTP/1.1 200 OK Content-Type: application/jwt
eyJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.eyJzdWIiOiJhbGljZSIsImVtYWlsIjoiYWxpY
2VAd29u ZGVybGFuZC5uZXQiLCJlbWFpbF92ZXJpZmllZCI6dHJ1ZSwibmFtZSI6IkFsaWNl
IEFkYW1zIiwiYXV kIjoiMDAwMTIzIiwiaXNzIjoiaHR0cDpcL1wvbG9jYWxob3N0OjgwODB
cL2MyaWQiLCJmYW1pbHlfbm FtZSI6IkFkYW1zIiwiaWF0IjoxNDEzOTg1NDAyLCJncm91cH
MiOlsiYWRtaW4iLCJhdWRpdCJdfQ.FJ v9UnxvQxYvlc2F_v657SIyZkjQ382Bc108O - U
Fh3cvkjxiO5P2sJyvcqfuGrlzgvU7gCKzTIqqrV74 EcHwGb_xyBUPOKuIJGaDKirBdnPbI
XMDGpSqmBQes4tc6L8pkhZfRENIlmkP-KphI3wPd4jtko2HXAd DFVjzK-FPicthis covers the fundamentals of the endpoints and about tokens , claim based authentication continually will try to see about the types of flows which can be adopted for secure sign in features.
