I am using a keycloak auth Spi with sms auth which works finde for browser flow.
My requirement is to use it with direct access grant. Therefor I have to create a formless challenge which conntext the auth session between two requests.
I am struggling with passing the parameters in the response. I've analyzed the request when entering the sms otp in the login form. I know the request object in detail but I cannot figure out where to get the required parameters from the sessin object within the authenticate methid.
Params are:
a cookie
code
client_id
execution
session_code
tab_id
My question:
Is it even possible to use this flow without a form?
Where do I get the parameters from?
Related
I'm currently using Firebase cloud functions as my mobile app's backend and I'm using Auth0 as my authentication provider.
My problem is that I've used Postman to send test login requests to my API and I'm able to get a valid JWT. I then deleted the user account through Auth0's user management panel and used Postman to test the login function again to see the type of response I would receive. Instead of receiving any errors, I receive a new valid JWT which allows me to access protected routes even though the user does not exist.
I've tried setting the response cache control to "no-store" and yet I'm able to receive a valid JWT. What could the reason be?
I am currently using a client-side React component to have a user login to Facebook via OAuth in my application. On the server-side, I use the npm package passport-facebook-token to validate the authenticity of the accessToken after a successful client-side login.
One practice I do not see often is in addition to asking Facebook if the accessToken is valid, shouldn't the server also check if the email provided by the client's payload matches the e-mail coming back from Facebook? Allow me to use defined client/server technologies to illustrate my question:
1) User uses React component on the client to authenticate with Facebook.
2) React component successfully authenticates with Facebook and fires an HTTP request to the server with an access token and the user's email.
3) The server, running Node.JS and passport-facebook, now needs to verify the authenticity of the access token directly from Facebook. Facebook does not care for an e-mail. It will just verify the access token.
4) Facebook returns a response to Node.js confirming the authenticity of the access token. The response also contains other metadata about the user, including their email and other profile data.
My question is, should Node.js take the email that's also coming back from Facebook's access token verification payload, and verify that it is what came back from the React client? Would this not prevent someone from brute-forcing an accessToken and require them to not only have an accessToken but also know who the accessToken belongs to? This could prevent a user from submitting a bunch of HTTP POST requests to the Node.js server attempting different access tokens. They would not only have to guess an access token assigned to the application's clientID, but also know the e-mail it belongs to. Is this an over-engineered approach?
Really the best way I can think of to make your OAuth accessToken and 'code' value less prone to brute-forcing is using a Cryptographic Number Generator to create a 128-bit length string of random data and encoding it with base 64 to use as your code. It's extremely unlikely that it would be guessed by a computer or by someone redirecting to and from the authorization endpoint and the redirect-uri with query parameters.
Another method of fortification is limiting the rate of authorizations by IP address (which you can do instead of email through Node.js) but that is usually not a problem for most well-equipped hackers. I highly advise the first method for creating a more secure service.
Your approach to validate the email as well as the token is a bit superfluous because Facebook's opaque user access tokens are inherently tied to email.
From Facebook
An access token is an opaque string that identifies a user, app, or Page
"opaque" is defined by Auth0 here
Opaque Access Tokens are tokens in a proprietary format that typically contain some identifier to information in a server’s persistent storage
In your case, the identifier is the user's email, and the server belongs to Facebook.
I will elaborate further. Here is your step by step with some edits:
User uses React component on the client to authenticate with Facebook, inputting both their email and password directly to Facebook. React component gets the token from Facebook on login success.
React component successfully authenticates with Facebook and fires an HTTP request to the server with an access token and the user's email.
The server, running Node.JS and passport-facebook, now needs to verify the authenticity of the access token directly from Facebook. Facebook does not care for an e-mail. It will just verify the access token because the access token is already tied to the email.
Facebook returns a response to Node.js confirming the authenticity of the access token. The response also contains other metadata about the user, including their email and other profile data.
This is Facebook's bug bounty program. If their OAuth was really as cracked as to require a second email validation, it would have been patched almost immediately by this incentive.
I have a saml Keycloak client which contains an Authentication Flow Override to a custom keycloak SPI authenticator built in java and deployed in the keycloak env. The authenticator is pretty simple, it displays a username field and takes that username, does a 3rd party check, then returns a verdict (go/nogo, yes/no, etc.)
I have a SAML SP sending a request to this keycloak client (as an IDP). The SP request has a LoginHint. When the Custom Authenticator receives this request in the authenticate method, it cannot retrieve the HTTP Post parameters because there are none.
When user enters their information into the custom authenticators form and clicks submit, and when the action method takes over, the new HTTP POST params are there.
I need to retrieve the loginHint in the authenticate method from the incoming SP SAML request.
anyone know how to do this? i cant read in the login_hint for the life of me.
login_hint and variations thereof belong to OpenID Connect (OIDC) implementations. In SAML you have to use RelayState (recommended) or an authentication request extension.
I want to send Keycloak user reset password email from my web app without using Keycloak SMTP configuration. For that I am trying to generate the reset password link but I am not sure how to generate the code in URL. Are there any API call to generate action code or full reset password URL ? Keycloak generate something like below. I need to generate same. That's the objective.
https://server.com/auth/realms/xxx/login-actions/action-token?key=ffdfdfdfd
There is no such API directly exposed in Keycloak.
Keycloak provides action tokens that permits its bearer to perform some actions, e.g. to reset a password or validate e-mail address.
Perhaps you could have a look at the action tokens SPI:
http://www.keycloak.org/docs/3.3/server_development/topics/action-token-spi.html
This way you can handle your use case.
I want to test an API which has the followoing instruction:
This API requires the caller to have an authenticated user web session.
When I login to the application and send a GET request in other tab it works. But I want to send a PUT request now so I cannot use browser. How can I have an authenticated user session while sending request through some other rest client. For eg: postman/ mozilla rest client.
I have tried logging into application through chrome and then using postman rest client. But it did not work. I have also tried Basic authentication providing application username and password.
So, given you mentioned you're using JWT, your API is most likely handing out this token upon logging in. At this moment your web client (javascript?) is probably storing it somewhere (cookie, local storage, session storage… – you can use your browser's dev tools to inspect). For all subsequent requests, this token is attached. If this token is getting persisted as a cookie, the browser itself takes care of attaching it to every request. If it is persisted somewhere else, your client has to "manually" attach this token to every request.
If you want to test your API call, first you need to login and get your hands on the token. Then, for all authenticated requests, you need to attach this token (probably as the Authorization HTTP header).