In application I generate token to user if login and password correct.
But I have security policy about password changing in some period.
When password expires I need enforce user to change password, and block API (except login and change password endpoints) until he changed password.
What's other endpoints should answer in this case?
My desicion:
Until password not changed endpoints (except user/login, user/chg-pwd) answer 403 Forbiddent.
Related
In my application, users can perform some tasks without login via the keycloak. After performing the task, I want to get an access token from keycloak by giving the username of the user to automatically log the user into application. Assume the user has a registered user account in keycloak too. is there a way to obtain an access token with username only?
In my application, users can perform some tasks without login via the
keycloak.
Unless those users are authenticated via some external IDP and you have established a trust-relationship between your external IDP and Keycloak (have a look at this SO thread for potential solution for a similar question to yours) in short I would say no.
From auth0:
Access tokens are used in token-based authentication to allow an
application to access an API. The application receives an access token
after a user successfully authenticates and authorizes access, then
passes the access token as a credential when it calls the target API.
The point is exactly that, exchanging some kind of authentication information (.e.g., username and password, or client secret) for a token that proves to your application that the user has authenticated successfully. Otherwise, someone could just enter your system as long as it had access to a username.
It sounds to me that you want to use the access token has means to pass information between Keycloak and your app, for that you have for sure better options.
I am new to JWT(Json web token). I have a question in JWT about identifying user with token(already login one time) and with out token(first time login).
Is it like that if I pass only username and password at every time of login and server will create new JWT for me? If this is true than isn't it be vulnerable for user if some one get access to his/her username password and try to login with different PC or browser.(as JWT is always store on cookies or local storage)
Following your schema, if an attacker stoles user credentials (username/password), then, he could login in the system and get valid JWT tokens.
If the attacker stoles the JWT, also could login in the system before expiration time, and use the provided services (for example change password if it is available)
Then the security question is: protect the credentials and protect the token.
Mainly use HTTPS
Set expiration time short and rotate tokens
Use "secure" storage for tokens
Be aware that changing passwords or permissions could invalidate tokens before expiration time. Maybe you need a blacklist
I'm in the middle of writing a RESTFUL API in Hapi, I could not figure out API authentication methodologies.
Assuming we're using SSL/TLS with HTTP/1.1, why do we need something like JSON Web Token (JWT), where we already have HTTP Basic Authentication. We may protect every endpoint with HTTP Basic Auth, so we wouldn't even need login routes like '/login'.
So, what's the point of those authentication schemes, OAuth's and JWT?
Thank you.
OAuth and JWT use tokens, not passwords. Tokens are uniquely generated per application and site. If someone steals a token, they have not stolen your password, and that token is only good for that session only.
Contrast this with basic auth, it's an actual user password. Not only can they re-use that password whenever they want, they can also use that password with any other service that uses the same password. Stealing a token doesn't allow that to work.
I am playing with WSSE Authentication (through Symfony2) and I have defined the following classic Login flow :
User enters its username & password & get the associated salt from the server
username & password are checked on the server (ajax call) through a WSSE header check
If Credentials are valid then, required data (i.e data that allow to re-generate a WSSE Header at each request) is stored on the browser
This is fully working.
Now, I would like to add the "Signin with facebook" feature. That's not a problem there's plenty of documentation on it, BUT, my purpose & my difficulty is to keep the WSSE logical working
As the user never enters its password if he logs in with Facebook, I am unable to generate wsse headers, and for this there is no documentation at all.
Would someone have already dealt with such an operation? Thanks in advance
the solution i found is following this order :
1) Create a webservice not under the wsse firewall but secured by a header token or something else like x-token : fdslkjl324l2lrkljlkfsjflkjfkljl2, which return the password encrypted from the database for the given user.
like for example : you should have an webservice to get user salt to encrypt user s password to authenticate through wsse API.
2) use the classic wsse webservices with generated token from the encrypted password following the wsse
now that you have the password encrypted you can simply authenticate under the wsse service.
The most important thing is you don t have to put the user password in plain .
I am developing a web service and I need to send a username and password to the service in a GET method. Is it OK to send this information in the uri as long as it's going over a secure channel like ssl? In other words, can I have a uri that looks like /users/{username}/{cleartext_password}?
Edit: Sorry, I think I was unclear. The web service is essentially just a database of usernames and hashed passwords. Imagine a desktop application that keeps usernames and passwords in a remote database. The end user types their username and password into the application and the application accesses the web service to authenticate the user.
So, the application will need to send an end user's username and plaintext password to the service. The service will take the username and password and check that the username and the hash of the password match the username and hashed password in the database. The application itself will have to authenticate before it can access the service, but I am just wondering what is the best way to send the end user's username and password to the service for authenticating the end user. I don't to use a POST method because I am simply authenticating and therefore not changing the state of the server. Sorry for the confusion.
Do this.
Send a "key" and a "digest".
The "key" is equivalent to a username.
The "digest" is a SHA1 (or MD5) hash of the key, the URI and a "shared secret" or password.
When the server gets this, it computes it's own version of the digest, based on key, URI being requested and the "shared secret" or password. Failure to match digests is a 401 error response.
If it's going over a secure channel, there's no problem sending the username and password as cleartext. I'd just recommend against ever sending them as cleartext through an insecure channel and against sending them repeatedly for each request.
What you could do is first authenticate to the web service (send the username and password via ssl as cleartext) and get a token from the server that it will recognize. Then send that token with each subsequent request.
Generally speaking this is not a good idea... This data will be present in a number of log files, consequently the data could be visible to people who should not see it. At the very least you should hash or encrypt it before sending it if you can.
Here is a related discussion for a little more detail... Is an HTTPS query string secure?
SSL does encrypt the URI, but definitely take a look at some alternatives.
HTTP Basic Auth is nice and simple, and well supported by browsers, webservers, etc
It also won't end up in log files to the same degree as URIs
NB: It's just some plain-text HTTP Headers, so definitiely NOT recommended for non-SSL apps.
http://en.wikipedia.org/wiki/Basic_access_authentication