When I enabled stateless sessions in OpenAm I get very large JWT token, that contains lots of information that I don't need.
Is there a way to change te composition of JWT-token? For example, I'd like to only have user id and user role in token.
Thx!
This is not possible via configuration. If you are using some open-source version of OpenAM then of course you can change it to your needs.
Related
My situation is this. I have a legacy Angular application which calls a Node API server. This Node server currently exposes a /login endpoint to which I pass a user/pwd from my Angular SPA. The Node server queries a local Active Directory instance (not ADFS) and if the user authenticates, it uses roles and privileges stored on the application database (not AD) to build a jwt containing this user's claims. The Angular application (there are actually 2) can then use the token contents to suppress menu options/views based on a user's permissions. On calling the API the right to use that endpoint is also evaluated against the passed in token.
We are now looking at moving our source of authentication to an oAuth2.0 provider such that customers can use their own ADFS or other identity provider. They will however need to retain control of authorization rules within my application itself, as administrators do not typically have access to Active Directory to maintain user rights therein.
I can't seem to find an OIDC pattern/workflow that addresses this use case. I was wondering if I could invoke the /authorize endpoint from my clients, but then pass the returned code into my existing Node server to invoke the /token endpoint. If that call was successful within Node then I thought I could keep building my custom JWT as I am now using a mix of information from my oAuth2 token/userinfo and the application database. I'm happy for my existing mechanisms to take care of token refreshes and revoking.
I think I'm making things harder by wanting to know my specific application claims within my client applications so that I can hide menu options. If it were just a case of protecting the API when called I'm guessing I could just do a lookup of permissions by sub every time a protected API was called.
I'm spooked that I can't find any posts of anyone doing anything similar. Am I missing the point of OIDC(to which I am very new!).
Thanks in advance...
Good question, because pretty much all real world authorization is based on domain specific claims, and this is often not explained well. The following notes describe the main behaviors to aim for, regardless of your provider. The Curity articles on scopes and claims provide further background on designing your authorization.
CONFIDENTIAL TOKENS
UIs can read claims from ID tokens, but should not read access tokens. Also, tokens returned to UIs should not contain sensitive data such as names, emails. There are two ways to keep tokens confidential:
The ID token should be a JWT with only a subject claim
The access token should be a JWT with only a subject claim, or should be an opaque token that is introspected
GETTING DOMAIN SPECIFIC CLAIMS IN UIs
How does a UI get the domain specific data it needs? The logical answer here is to send the access token to an API and get back one or both of these types of information:
Identity information from the token
Domain specific data that the API looks up
GETTING DOMAIN SPECIFIC CLAIMS IN APIs
How does an API get the domain specific data it needs from a JWT containing only a UUID subject claim? There are two options here:
The Authorization Server (AS) reaches out to domain specific data at the time of token issuance, to include custom claims in access tokens. The AS then stores the JWT and returns an opaque access token to the UI.
The API looks up domain specific claims when an access token is first received, and forms a Claims Principal consisting of both identity data and domain specific data. See my Node.js API code for an example.
MAPPING IDENTITY DATA TO BUSINESS DATA
At Curity we have a recent article on this topic that may also be useful to you for your migration. This will help you to design tokens and plan end-to-end flows so that the correct claims are made available to your APIs and UIs.
EXTERNAL IDENTITY PROVIDERS
These do not affect the architecture at all. Your UIs always redirect to the AS using OIDC, and the AS manages connections to the IDPs. The tokens issued to your applications are fully determined by the AS, regardless of whether the IDP used SAML etc.
You'll only get authentication from your OAuth provider. You'll have to manage authorization yourself. You won't be able to rely on OIDC in the SAML response or userinfo unless you can hook into the authentication process to inject the values you need. (AWS has a pre-token-gen hook that you can add custom claims to your SAML response.)
If I understand your current process correctly, you'll have to move the data you get from /userinfo to your application's database and provide a way for admins to manage those permissions.
I'm not sure this answer gives you enough information to figure out how to accomplish what you want. If you could let us know what frameworks and infrastructure you use, we might be able to point you to some specific tools that can help.
I have read a lot about OIDC and OAuth2, I know the id token is mainly used for the client to know who the user is and whether the user is still online currently.
Furthermore, Id token can prevent a class of impersonation attacks [You can find more details in this article].
But what if the id token is stolen? Can the attacker uses the id token to impersonate a user?
In our project, we just ensure https besides the OIDC. What else security consideration should I take to mitigate the impersonation attacks?
The goal or purpose of OIDC is not to be more secure than OAuth2, and this kind of comparison doesn't make sense. They solve different problems.
Let's start with OAuth2. In very short and somewhat simplified, OAuth2 solves the problem when a website holds data of a user, and that user wants to grant access to some of their data to another website. Say you have a Facebook account, but want to allow my application to access some of your data on Facebook, or for a more concrete example, you want to allow my awesomeapp.com app to post a link to your Facebook wall. For this, my website redirects you to Facebook, you log in, get an access token, and send that access token back to my website so that I can use it in your name to get what you allowed me to.
Note that there is one thing missing. I have no idea who you are. I just had an access token, with which I can do stuff, but I don't have identity info about you. Sure, this can be abused in different ways, the access token can hold your email address or whatever, but it's limited, the size matters, and there is no standard way.
At least not until OIDC comes in the picture. OIDC provides the identity element.
The purpose of the ID token is to provide identity info, to tell me claims about who you are. It may claim what your email address is, what security groups you are in, which company you work for, or anything else. Also it may be used to download more claims, in case they don't all fit in the actual token (see userinfo). These claims come from the Identity Provider, say Facebook, which my application then has to trust of course, i.e. I will believe whatever Facebook tells me about you.
This is all possible with pure OAuth2, but there is no standard, well known way to do so (or well, it is OIDC :) ). You could invent and implement something yourself, but these things are more complicated than they may first seem to be. That's why OIDC was invented, so you don't have to. But after all, OIDC is just a way to use OAuth2 to provide identity. In the end, it's just an extended OAuth2 if you like.
As for what security considerations you need to take into account - this part of your question is way too broad and can't be answered unfortunately. Security is a very complex topic.
I'm not really a security purist so my additions to Gabor's points are from a more practical viewpoint, as someone responsible for building well architected UIs and APIs:
An id token represents proof of authentication to a UI
An id token is NEVER used by APIs, which must use access tokens instead
An id token is the only type of token a UI should ever read, and it is mandated to have a JWT format
For Web UI logins an id token provides extra security, since it enables the UI to validate tokens and protect against some types of token substitution attack - so yes - OIDC is more secure
An id token is sometimes needed in order for logout to work
You should ALWAYS use a certified security library that does this type of work for you, rather than reading tokens directly in your own code.
In short I'm implementing a cloud for my boss. This cloud will be mainly used by angular2 based front-end applications, including mobile application. This cloud must have multi-tenant support so the company can monetize this investment. He prefers not to be reliant on third party providers.
As a platform I intend to use the wso2 products as the ecosystem of the cloud. Information can be found here. The one for this question is the wso2 identity server (installation on premise). you can find more information here.
The micro-services will be based upon spring cloud.
For security I want to implement this OAuth2 pattern, where an opaque token is shared with the front-end and an enterprise service bus translates this inbound token to an identity token containing RBAC information to provide stateless identity within the cloud.
This is the part where it becomes unclear. For securing front-end applications I need an identity store. For web applications it is preferred to use the email and password combination for login. When I look to OpenLDAP or similar, I tend to find username and password combination. What technology would be best suited as identity provider using email and password combinations with role based access control and multitenancy? Perhaps I'm still missing some basic understanding, any help would be appreciated.
Please check JWT. OAuth needs another authentication server to Authenticate & Authorize users. JWT is best suited way for microservices architecture.
You just need to verify the JWT token's signature. Check whether it's signed by any of your microservice or not to Authenticate the User(it's simple).
For implementing Authorization, you can add role level information in your JWT token when you are generating the token.
Such that, UI would always access your services with the token and you would always get this information in your JWT token in all the microservices. Make use of Spring security to provide access of certain resources based on the Role.
Please check out this blog for more information on securing your microservices.
Hope this helps.
OpenLDAP has everything needed to accomplish this. You can lookup a user via its email address and then you can authenticate the user further. Wso2is has everything needed to make this work. It is just simple configuration. Information can be found here.
I am trying to research what options are available when using 3rd party authentication for a web application. I would like to have the ability to customize which information is submitted when a user authenticates as well as control the branding of the login.
I would also like to be able to manage how password recovery/reset is handled.
Any suggestions?
EDIT: I wanted to add more information to detail what I was looking for. Essentially and am wanting to hand off all the password reset, authentication, and management to a third party. Just like OpenID. However, I don't want to user/customer to have to go to an OpenID provider as I think it could be confusing. I would like them to enter a username and password on my site but be authenticated by another provider. Does that make sense?
If it's helpful still, I compared (5/18/2015):
Auth0
AuthRocket
UserApp
DailyCred
Conclusion for me was Auth0, because while all the features are very similar, it felt the most legitimate, as in it's not a start-up that might disappear in a few months. Now, the reason that was super important for me was because login is a foundational requirement, so I need to believe as a customer that the Authentication as a Service will be up for as long as I will be.
Here's the full comparison story:
https://medium.com/#bsemaj/authentication-as-a-service-comparison-5-quick-lessons-for-b2b-businesses-e7587275824c
I know that web apps don't normally tie their sessions to the sessions of their login providers, but I have a requirement in which I need to detect when the user signs out of their login provider so that I can sign them out from our application as well.
I currently have passport set up on my Node.js server. The login was very easy to implement and it's been working fine, but I haven't been able to find documentation on polling the current status of the user's session on the provider's end. Does passport provide a means to check this status? Calling the authenticate route again always does a redirect so I'm looking for a simple and ajax-friendly way to get a yes or no answer to the question: 'Does the user still have a valid session at their login provider's end? Thanks
This is going to depend on the provider and the protocols they choose to implement. What provider are you using? What protocol is used to authenticate?
Currently, SAML is the only widely-used standard which defines facilities for federated session management. Even in that case, I'm not sure how common those profiles are, since it is typically used for authentication only.
As far as Passport is concerned, that module is focused solely on authentication. Session management and logout are separate (but related) concerns. I'd like to develop other modules that work in conjunction with Passport; however, lack of deployed standards make it difficult.