In an OAuth 2.0 setting, suppose that, besides OAuth authorization (optionally using OAuth scopes), you want the resource server to use SAML assertions to implement fine-grained authorization checks, for example allowing certain operations only if the 'consumer' holds a 'Gold' status.
1) Is it possible for an OAuth acces token to "convey" a SAML 2 assertion? How?
2) If not, is there a way to use both Oauth and SAML 2 to obtain a similar result?
3) Is there a way to use OAuth by its own (without SAML) to obtain a similar result?
Please note that I know that you can use a SAML assertions as user credential when you are getting a token but here the point is different: what is needed is to use a SAML assertion when accessing to the resource, that is when using a token.
Related
While configuring OAuth 2.0 based authentication servers like Auth0, Duo, etc. for our application, we need to create and send JWTs as part of authorization request as well as to get access token. The required arguments to be included in these JWTs and their values are explained in the documentations for the respective servers.
Is there a common endpoint according to OAuth 2.0 where we can get which arguments are required and what are their expected values for creating the JWT?
I am implementing front-channel SAML 2.0 SSO golang Service Provider, with Okta as my Identity Provider (this is just a POC and should eventually work with any IdP).
Implementing the sign on process was straightforward with saml2 package. I've created the login endpoint that redirects to the SAML application login URL at the intended IdP, as well as the POST callback endpoint which is properly receiving the SAML assertion and is able to validate it. After that a session with a random cookie is created with the same TTL as the Identity Provider session TTL. So far everything works well (I haven't implemented Single Sign-Out yet, but I'm planning to).
However, when some time passes and the session expires, I'd like to renew it only if the user is still logged in with the Idp and hasn't been removed from the SAML Application. I would like to avoid redirecting the user to perform SSO again with IdP, because it would mean that if they are still logged in, they would be redirected back to the home page of my application. I wasn't able to find great sources on my options to go about it online.
Questions:
1.1 One solution that comes to mind is storing the requested URL in the RelayState parameter, whenever the session has expired, then redirect the user to the IdP SSO URL. When the redirect returns to the SAML callback POST endpoint, check the RelayState parameter and if set, redirect back to that (original) URL. That means that for users that use the system continuously, I would have to request Assertions very often. Does that make sense?
1.2 A second solution that comes to mind is to implement a back-channel of communicating directly from my SP to the IdP. That would allow me to verify a user is still logged in 'behind the users back'. If that's a sound idea:
a. Do I need to have dedicated code for each IdP?
b. Do I need to load an API key to the IdP which would allow secure communication?
c. Do I need to upload a public certificate to the IdP that would be able to verify that my SP signed the requests?
Will using the Assertion to get an OAuth 2.0 Access Token help me in achieving this?
I've chosen SAML 2.0 for now, since the environment is an enterprise oriented one and I thought it fits well with it based on what I read. Would using OpenID Connect instead help achieve my goals easier and fit well with enterprise oriented products?
I have a react app that uses Keycloak endpoint token_endpoint to authenticate the user. The problem I'm facing now is how to update/refresh this token. I know I could use a refresh token but that's a bad practice since has security issue when it comes to a web application. It seems to me that the best approach would be to use Silent Authentication.
Unfortunately, I couldn't find any example or documentation that allows me to achieve this. In case you guys have another approach I'm open to suggestions.
Tks
It would consist just of providing the prompt=none parameter on the authentication request as stated in the OpenID Connect 1.0 Core spec:
https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest
prompt OPTIONAL.
Space delimited, case sensitive list of ASCII string
values that specifies whether the Authorization Server prompts the
End-User for reauthentication and consent. The defined values are:
none
The Authorization Server MUST NOT display any authentication or
consent user interface pages. An error is returned if an End-User is
not already authenticated or the Client does not have pre-configured
consent for the requested Claims or does not fulfill other conditions
for processing the request. The error code will typically be
login_required, interaction_required, or another code defined in
Section 3.1.2.6. This can be used as a method to check for existing
authentication and/or consent.
Authenticate to obtain an access_token with /auth (prompt=login).
Just call OIDC /token with grant_type=refresh_token to refresh token with the access_token. the new response include access_token, refresh_token and so.
After that you must update them for the new api calls.
I have written a web application which makes REST API calls to a message broker. The message broker contains already written REST APIs to which can be used to get message broker data. The message broker is written in a way in which each REST API call sends the user name and password which is encoded with base64. I need to make a login to my web app and authenticate it with OAuth.Does anyone know how to do this? How to authenticate the REST APIs with OAuth?
Step 1: Add OAuth 2.0 to your web server. This is very standard with lots of libraries available. You did not specify the Identity Provider that you will use (Google, Facebook, Auth0, Okta, etc), but each vendor has documents and libraries for you to use in your desired language.
Step 2: Add an Authorization Header to your API calls. The standard method is to add the HTTP header Authorization: Bearer access_token when making an API call.
Step 3: Add OAuth token verification to your API. When your API receives a request, it extracts the Authorization header and verifies the Bearer token. How this is done depends on the Identity Provider. For example, some vendors provide a Signed JWT (which you verify with the vendors public certificate), others provide an opaque access token (which you verify by calling the vendor's token endpoint). Add internal caching of tokens so that you don't need to verify on every API call.
If you understand OAuth 2.0 the above steps are straightforward to implement. If you don't Oracle has a set of videos which are excellent for getting started understanding OAuth.
Oracle Cloud Primers
If your desired OAuth implementation does not require users logging in and is a server to server service that you control on both ends, then you can use just part of OAuth which is Signed JWT (JWS). You create a Json data structure with your desired content and sign it with a private key. This creates a token that you can use in the above steps. You would then validate the token using your public key. You can use self-generated keypairs generated by OpenSSL or similar products for your signing and verification.
I'm trying to find out if it is possible for ADFS to send two types of tokens on one authentication ?
We have external systems working with JWT tokens but also systems with SAML tokens. We like to receive a JWT token and SAML token as a response on one authentication request to ADFS.
I was reading up on the following: https://learn.microsoft.com/nl-nl/azure/active-directory/authentication/concept-mfa-howitworks but this seems to be consecutive means of authentication not what I'm looking for
No - it's either one or the other.
It's not an ADFS issue.
That behaviour is proscribed by the protocol.