From my understanding user session info for OpenAM only can be access by Session API. And we need to use post-auth plugin to extract those info and insert to cookie.
By question is:
- Without using post-auth plugin, is that a way to configure OpenAM (via UI) return specific user session attribute(s) (eg. AuthType) to it's cookie?
Thanks
OpenAM policy agents can store session attributes to cookies or headers (see realm -> access control -> Agents -> Your agent -> application).
The other option would be to use OAuth flows (Open Identity Connect) - which can present user attributes in a JWT token as part of the authentication process. Your client would have to decode the JWT token and extract the attributes.
Related
Background
I'm trying implement a browser-based login for a native mobile app from an existing Single Page Application. It uses WebView to render the SPA and it uses Keycloak OIDC as its Identity Provider.
The SPA and IdP is located in completely different domain and authentication is done by redirecting to the SPA domain after a successful login and retrieving the active session (cookie) from IdP domain in one of the SPA's server. The authentication check is achieved by using keycloak middleware which I believe is the protect.js
Summary:
Perform Login -> auth.idp.com
Redirect -> best.app.com
Is Login? -> best.app.com/login
Does auth.idp.com session exists?
User is logged in, redirect -> best.app.com
Token is passed in the URL and is stored only in memory
Token is used to establish WebSocket connection
Issue
Based from the spec, the authorization should happen in the browser / in-app browser, and authorization code must be passed via custom URL scheme. Having that in mind, the SPA that resides in the WebView of native mobile app will never establish a session from IdP's domain since this will be delegated from the browser which is on a different process and obviously using a different cookie store than on WebView in the mobile app, which makes our existing solution to break because it is relying on the IdP's domain cookie.
Proposed Solution
The issue I described above can be mitigated by cutting the reliance on IdP's session and by managing the SPA's own session, which basically means storing the token persistently that can be obtained from the IdP (which the current solution doesn't do).
(I don't want to detail much of the solution since I just want to focus first on the concept of storing the token. I think it's better for me to put this in a separate discussion if someone is interested)
Opinion
It seems like the current implementation doesn't really follow the best practice for OIDC flow but somehow, Keycloak has made some middleware to remove the need to use these tokens (authorization code, id token, and access token)
Relying on IdP's session when implementing SPA or non-web apps seems like not an option, because there is no way to obtain the cookie without reloading the page and provided that IdP session exists in the same cookie store as the SPA.
Redirecting to the IdP's session is not a good user experience for SPA. See the same sentiment here but it seems it does not have any answer: https://lists.jboss.org/pipermail/keycloak-user/2016-October/007937.html
Question
With regards to my proposed solution, i.e., storing the token retrieved from IdP, is there any security flaw or something non-industry standard it's going to introduce? If so, what are those?
Is it typical for OIDC flow to rely on IdP's session (cookie) to check if user is logged in or not?
If answer from #2 is NO, is that authentication flow specific for Keycloak only or does it exists for other IdP as well?
If answer from #2 is YES, is it common for IAM solution to programmatically check if the IdP domain contains a valid session (cookie)?
Is the current implementation flawed knowing we are aiming for SPA?
How does Keycloak handle sessions?
If you're using the default Keycloak middleware in your server and use keycloak.protect() for protecting endpoints, it checks on the request.session['keycloak-token'] which contains the access_token that was created during the token request after user login. If this exist and valid, it means user will not be redirected to Keycloak login page.
How does Keycloak create sessions?
Providing username and password which can be done manually using Keycloak's login page.
Cookies - if you pass valid cookies that are recognized by Keycloak, i.e., KEYCLOAK_SESSION, KEYCLOAK_SESSION_LEGACY, ..., a session will automatically be created.
How to access protected resources?
When using the keycloak-connect client adapters, you can access protected resources if the user agent (browser/app), has a valid session in your server OR if the request contains valid Authorization header.
Standard Solution
Access protected resource via Authorization header and use access_token which the keycloak.protect() also accepts. You can obtain this token in a standard way using Chrome Custom Tabs for Android and ASWebAuthenticationSession for iOS. You can also use AppAuth (iOS, Android) to lessen your work.
Store the refresh_token and access_token from native mobile and inject this in the HTTP request of WebView if possible.
Have a way to check for access_token validity and use refresh_token to request for a new one. If requesting for a new one fails, i.e., the authorization server verifies it's not valid anymore, that means users would need to re login again.
By using the standard solution I have proposed above, you should not need to create a band-aid solution for your issue. Hope this helps anyone that have faced similar issue.
I want users to be able to log in with various methods - via Auth0 - to my application.
But I also want to store user info in my own database - and merge logins by ID.
i.e. if I login with a facebook account and google account, linked to the same email address (and verified) then they will end up with the same user in my application.
After reading this post: OAuth and external auth providers, it seems maybe I would end up needing to configure my own auth service and convert the auth0 access token into my own ID/access_token - effectively representing a session in my application. During the conversion from auth0 token to custom token, I'd check for an existing account with email, otherwise register a new account.
Is this the most feasible way to achieve this? I have a feeling it'd be simpler to use 1 token issuer rather than 2.
Effectively this would be a double code exchange.
Redirect Auth0 Login -> Receive code in URL -> exchange code for Auth0 token -> exchange Auth0 token for a proprietary token (relating directly to - and possibly containing cached fields of - the user in the database).
Use finally acquired proprietary token for authorization with my services
Hi I am trying a simple authentication of a webapi using AzureAD. In that when we add the connected services using the Azure AD, the Startup.cs class adds the below code
app.UseWindowsAzureActiveDirectoryBearerAuthentication(
new WindowsAzureActiveDirectoryBearerAuthenticationOptions
{
Tenant = ConfigurationManager.AppSettings["ida:Tenant"],
TokenValidationParameters = new TokenValidationParameters
{
ValidAudience = ConfigurationManager.AppSettings["ida:Audience"]
},
});
When i went through some of the authentication tutorial, i am seeing people are asking to use some thing like the one shown below
app.UseCookieAuthentication(new CookieAuthenticationOptions());
app.UseOpenIdConnectAuthentication(
new OpenIdConnectAuthenticationOptions{....
}
What's the difference between these 2, aren't we supposed to be using AzureAD options going by the name and since we are using the AzureAD Connected Services for Authentication of the webApi. Can some one clarify the same?
Cookie Authentication
Cookie authentication uses HTTP cookies to authenticate client requests and maintain session information. It works as follows:
The client sends a login request to the server.
On the successful login, the server response includes the Set-Cookie
header that contains the cookie name, value, expiry time and some
other info
The client needs to send this cookie in the Cookie header in all
subsequent requests to the server.
On the logout operation, the server sends back the Set-Cookie header
that causes the cookie to expire
Note: Cookie authentication is vulnerable to Cross-Site Request Forgeries (CSRF) attacks, so it should be used together with other
security measures, such as CSRF tokens. For more details you could take a look here
Azure Active directory Authentication:
As you know Azure Active Directory is a modern Token based authentication which provides Single Sign-On (SSO) that allows a user to use one password (or smart card) to authenticate to multiple servers on a network without reentering credentials. This is an obvious convenience for users, who don’t have to remember multiple passwords or keep going through the authentication process over and over to access different resources.
Main thing is AAD uses JSON Web Token(JWT). On receiving the credentials from client the server validates the credentials and generates a signed JWT which contains the user information.
Its also support most popular modern authentication protocol as following.
OAuth 2.0
OpenID Connect
WS-Federation
SAML 2.0
Note: the token will never get stored in server(stateless).
So the main difference is cookie based authentication usually stores your user sensitive information on server because it maintains session which seems vulnerable on the other hand token based authentication is secure and don't preserve sensitive information.
see the basic difference of these tow architecture below:
Select Right Authentication:
Here I am showing you a flow chart which enhance your idea to choose right authentication for your application. Take a look below:
You could also have a look here for better clarity. Thank you very much. happy coding!
i am totally confused about the usage of OAuth and i am not sure how to use oauth for my szenario. At the moment i use a "pure" JWT approach which looks like that:
Client (JavaScript Application) send login and password to my Rest-Endpoint (Server (Java)).
Server validate user informationen, read / generate some user roles and wrap it in a JWT Token (with a secret)
Server send JWT Token back to client
Client will perform additional Rest-Calls with Authorizationen Header
Server validates Token with private secret and grand access based on roles/user
Now i think about the usage of OAuth but i am confused how to use it to realize the szenario.
I registered an application at "auth0".
I use a JS library to redirect to the login process of auth0, login via auth0 account and consume the id_token and access_token
= i can send the id_token (JWT with RSA256) to my rest api, validate it with the public certificate and can extract some user information
but:
a) i have read that i should not use the id_token to access my api. Instead i should use the access_token (which is not in JWT format and will not give me any information about the user) and use the access_token to query for the user information? That whould be the case for every request?!
b) i don't see the point where the user roles come into play. When i have some operations (rest endpoints) which are only allowed for "admins" or "customers". I don't see any possibility to define them.
You see i am a little bit confused, i hope somebody can clarify all the things.
Thanks a lot
Chris
a) Both tokens you use should be in JWT format and you should use access_token for authenticated queries. The access_token not necessarily contains information about the user, so on server side you usually can decide only that the token is emitted by the token service and is valid. If all these checks are passed, you should accept it as an authenticated user.
b) User roles can be placed into the access_token's payload section as an additive claim (e.g. role=admin,datawriter or role=customer,listreader) like many other things.
I hope it helps.
a) Sounds like you are getting an opaque access_token back and not a JWT. You'll need to create an API in Auth0 (similar to the application/client you already created). Then you pass that identifier in the audience parameter when you authenticate. Then you should get a JWT back, and that will have a sub parameter which is the Auth0 ID of the user, which can help you identify who the user is. I believe you could also use Auth0 rules if you need to put more identification info into the token. See here for a full explanation of the opaque vs. JWT access token: https://auth0.com/docs/tokens/access-token
b) Roles are tricky. I believe Auth0 would suggest that you create scopes on your API, and then request the scopes needed during login. Auth0 Rules would then be used as a sort of "glue", to adjust scopes that were requested but not permitted for the authenticated user. They also have an Authorization Extension you can use to help facilitate some of this. Another option could be storing role info in the user metadata, and using rules to put that info into the token. Finally, the option we chose was to not use Auth0 to define our roles. We let Auth0 authenticate, and once authenticated we check access in our system for the authorization side of things. Lots of options.
I want to implement saml using passport module of node js using my own idp. But the below links that i found are using some openidp/adfs/shibboleth etc.
https://github.com/bergie/passport-saml
https://github.com/lmarkus/passport-saml-encrypted
https://www.npmjs.com/package/saml2js
I have created two localhost apps ,one functioning as sp(service provider) ,other as idp(identity provider) and while redirecting from sp to idp i am sending the encrypted saml and than i am validating the user using passport ldap module,but i need to know that whether the certificates/public/private key needs to be present at idp side also ? How will idp send back the response and in what format ?
If you are signing the AuthnRequest or encrypting the token then the IDP needs the public keys.
The SP needs the IDP token signing public key.
The IDP will send back an AuthnResponse which contains the SAML token which contains the assertions (claims).
The easiest way to see this is to use the Fiefox SAML tracer add-on.