Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
I'm trying to build an app based on a couple with Laravel and Vuejs.
I've implemented a method in Vue that sends POST login and gets an accessToken from back's Laravel. My next challenge is to get an authorized user's data to show in NavBar and so on. What is the right way to do it?
Way 1: The login method on the app's back returns not only the accessToken. He also puts a user's data into the response. So, after the login request, Vue gets the accessToken and user's data that I put into localStorage inside of Vuex.
Way 2: The login method returns only the accessToken. After getting accessToken, Vue makes one more request to get a profile of the authorized user by the accessToken.
What's the correct way to get an authorized user's profile?
Both approaches are correct, but I think there is no need to get the profile with the login response .
I will only return the accessToken and store it somewhere safe, and when you need the user profile you make another request.
and for showing different types of NavBars,you can use an event emitter to trigger different actions (login, logout)
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 days ago.
Improve this question
I am currently in the process of designing a network of servers and databases for a project.
One key aspect of this project is the implementation of a central authentication server which will utilize session IDs to track sessions. These session IDs will be stored in cookies and sent back to users upon successful login.
Note: I understand that nextjs can work as both a front end and a back end. For reasons I will not get into here, nextjs is being used as a front end, and a separate central authentication server is being used for authentication. There are other servers/databases that will store data that users can access if they have proper permissions levels.
In step 1, I have no questions.
In steps 2 and 3, when the cookie is sent back to the nextjs server, what is the best practice for nextjs to determine the authorization level of the user?
I believe it's important that...
- Nextjs should know what navigation tabs to show, etc., when it renders the page for the user.
- Nextjs should also know what pages the user is allowed to visit. If the user is asking for a server-side rendered page that it isn't allowed to visit, it should be blocked
Possible option: Here, do I include some sort of JWT with authorization levels? It is my understanding that nextjs may be able to read these JWT authorization levels in middleware, then deny certain page requests that the user has by reading the JWT each time they request a page. Perhaps, even without middleware, functions could be used within the pages that would run server-sided, checking the JWT permission levels. Note that, in order for the nextjs server to know what the authentication levels are for the user, the tokens would have to be created in the central auth server, and then sent to the nextjs server.
Side thought: It seems that if I were to implement a function that checks the authorization level on a SPA, there would always be a way that a hacker could at least visit the blank page, correct? In other words, the only way to truly hide pages and navigation tabs from a hacker would be by somehow checking authorization levels server side (server-sided rendering), and then sending back a rendering of the page that only shows items related to the exact permissions of the user?
Overall, I would greatly appreciate any advice or insight on the best methods for authorizing users and limiting access to pages and tabs based on permission levels. While cookies will be used to store the session id and determine the data that users can receive when making API calls, additional measures such as JWT may be necessary for authorizing users to view specific pages. Is it common to utilize a combination of session/cookies and JWT for this purpose? What are the recommended best practices in this scenario?
Thank you for your assistance.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 12 months ago.
This post was edited and submitted for review 12 months ago and failed to reopen the post:
Original close reason(s) were not resolved
Improve this question
We are using Keycloak for authentication (OIDC):
the user input his Username/Password and enter the Frontend Browser page (Client)
Rest API calls to the Backend (Server) has the Bearer Token (= access token) in the Header
calls are queued in RabbitMq
after a long running task the stored Bearer token from the next running task is already expired and has to be renewed by a Refresh Token
Now the scenario: someone is able to steal the Refresh Token and get always new valid access tokens. Keycloak should recognize this by "Automatic Reuse Detection" and requires re-authentication to prevent this!
We tried this out in Postman and were able to use the same Refresh Token on both sides (different Clients in the same Network) several times without any problems.
An other possibility would be to use Revoke Refresh Token to ON and Refresh Token Max Reuse to 0. But then it is not ensured that the valid user is still able to authenticate because of race condition with malicious users:
The Attacker uses the Refresh Token before the valid user
the Refresh Token becoming invalid for the valid user due Revoke Refresh Token
What are the best practicies here? Any kind of help is very appreciated!
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
My main problem is getting the token. I can’t go further than this step.
In the Linkedin API's docs there are two ways described to obtain the token.
Witch is the correct one?
1) https://developer.linkedin.com/docs/v2/oauth2-client-credentials-flow
2) https://developer.linkedin.com/docs/oauth2#configure
I understand that in order to use the new Linkedin API (the partners one) I should use the first one (https://developer.linkedin.com/docs/v2/oauth2-client-credentials-flow)
Here is my petition:
https://www.linkedin.com/oauth/v2/accessToken?grant_type=client_credentials&client_id={MYCLIENTID}&client_secret={MYCLIENTSECRET}
The response:
Error "access_denied"
error_description "This application is not allowed to create application tokens"
And I get stuck here.
With the second one (https://developer.linkedin.com/docs/oauth2#configure) I actually get a token:
https://www.linkedin.com/oauth/v2/authorization?response_type=code&client_id={MYCLIENTID}&redirect_uri={MYURIREDIRECT}&state={STATERETURNED}
This returns the code (and the State) which I use to make the token request:
https://www.linkedin.com/oauth/v2/accessToken?grant_type=authorization_code&client_id={MYCLIENTID}&client_secret={MYCLIENTSECRET}&redirect_uri={MYURIREDIRECT}&code={CODERETURNED}
And I get the token. But this isn’t the correct way to do it, is it?
By default you will need to use the authorization_code flow to obtain an access token. Per the documentation the client_credentials flow is not enabled by default and needs to be specially enabled by LinkedIn.
https://developer.linkedin.com/docs/v2/oauth2-client-credentials-flow
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I am implementing OAuth for a project, and I want to know the best way to handle refresh tokens.
The API I call will return a JSON object with access_token, expires_in, and refresh_token.
So I was wondering, is it better to:
Calculate the time when the access_token will expire, store that in the database. Check that the access_token is not expired every time I make an API call, and if it is expired then use the refresh_token to get a new access_token.
(Additional Question: how do I make sure that the time which I calculate for the token expiration is accurate? Because the expire_in value probably starts from when the API server generated the key, and not when I receive it.)
OR
Just try to make the API call with the access_token every time, and if that returns with an error then use the refresh_token.
I am also open to other options of implementing this.
The client should always be prepared to handle an error returned from the API that indicates that the access_token validation failed. Depending on the implementation the access token may have been revoked or declared invalid otherwise.
The client may then use a refresh_token to get a new access token and try again. So you can choose to implement 1. but it does not free you from implementing 2. as well, so you may choose to stick to only implementing 2 and minimize the amount of code required.
Of course if you want to prevent errors from happening as much as possible you could implement 1. to optimize the number of calls and reduce the number of errors in the whole process.
This article explains practices by some big cloud services:
http://blog.cloud-elements.com/oauth-2-0-access-refresh-token-guide
However, IMO, the refresh token should have an expiration time, say 1 year. It should change when a new access token is issued using the refresh token, however, the expiry date should remains the same. When you need a refresh token forever, just issue the refresh token with max date value. Also, make sure to mark the old access and refresh tokens as deleted when issuing the new refresh token.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
Does Google Go support decoding of basic access authentication calls? How do I get the username and password from the http.Request?
Go does not seem to intercept basic authentication when it is typed as an URL in a browser, but it does allow one to get it from some other applications calling it.
For example, using a simple Python code for HTTP JSON RPC:
from jsonrpc import ServiceProxy
access = ServiceProxy("http://user:pass#127.0.0.1:8080/")
print access.getinfo()
And in Go calling:
// r *http.Request
r.Header["Authorization"]
One gets this string:
[Basic dXNlcjpwYXNz]
And
dXNlcjpwYXNz
Base-64 decoded gives
user:pass
So some basic authentication in Go is possible, although it might not be something one can rely on.
There seems to be no way to get the user-provided authentication info, but you can provide the valid username and password for HTTP Basic Authentication by calling SetBasicAuth.