I have a client that uses the orderhive service as an inventory management system, So I do not understand the auth with Laravel 8. What I understood from this link orderhive API docs is that I will get two tokens from the client app_token and refresh_token, then I should send them somewhere / somehow to AWS to get a bunch of tokens then send the request.
I do not understand that process altogether, and I hope there is any package or something built in Laravel to ease that process. Like if the AWS SDK itself could be easier to integrate. All tutorials and lessons are about S3 images, so any info would be appreciated.
The process of dealing with such a scenario is as follows:
you will have all the app credentials
use the credentials to grant access (code grant - JWT) as an example
after you grant the access you shall have (access_token)
the access token will be valid for a certain time (e.g. 8hours)
use the access token to generate a (refresh_token)
store the access_token and the refresh_token and date_generated somewhere
whenever you want to make a call to the API just use the stored tokens
if the access_token expired, use the refresh_token to regenerate a new access_token
when generating a new access_token via the refresh_token, the response should contain a new access_token and new refresh_token
replace the new tokens with the old ones
feel free to ask if any point was not clear for you.
Related
I'm creating an API server which will be consumed by a mobile app that I will work on later. I have yet to see any reference of API best practices related to user flow and returned data even after searching for several hours.
My question is whether the login response of an API should return the a personal access token with the refresh token along with the user info? Or should I just return the token and make another API call for getting the user info.
I could just do what I have in mind but I'm trying to learn the best practices so that I don't have to adjust a lot of things later.
I need suggestions as well as good references related to my question.
Thank you.
It depends on what you are using for your authentication. If you are using libraries like Laravel Passport or JWT, you can have the token endpoint which returns the access token, refresh token, validity period and the token type (Bearer). You can then have an authenticated endpoint which will be used to get a user's profile based of the token passed in the request header.
However, if you go through the documentation for those libraries, in most there is an allowance to manually generate a token. You can use this in a custom endpoint that will return the token as well as the user profile Passport Manually Generate Token.
If you are using JWT, you can also embed a few user properties in the token itself. The client can the get the profile info from the JWT itself without having to make a round trip to the server. Passport ADD Profile to JWT
If you have a custom way in which you are handling authentication, you can pass the token as well as the user profile in the same response.
In the end, it's up to you to decide what suits you best.
Have you looked at OpenID Connect? It's another layer on top of OAuth 2.0 and provides user authentication (OAuth 2.0 does not cover authentication, it just assumes it happens) and ways to find information about the current user.
It has the concept of an ID_token, in addition to the OAuth access token, and also provides a /userinfo endpoint to retrieve information about the user.
You could put user information in your access token, but security best practice is to NOT allow your access token to be accessible from JavaScript (i.e. use HTTP_ONLY cookies to store your access token).
I'm creating a SPA app with Vue.js (will be stored on remote server) and I'm confused as to what I should use.
At first I considered the use of Passport, but I don't understand how to make an API with Passport for 1st party only. Also I don't understand, how to make it quite secure if I need to send to the server my client-secret and client-id.
Then I read more about JWT, but there's no scopes for my tokens and no refresh tokens. It means if somebody stole the token from localStorage, then he will get access to this user permanently.
And one more question about the token access and API. I read a lot about different token expiration when it depends on its importance. It means token for changing password must be valid for a period of 5 minutes, but token for reading some information should be valid for 6 months. Is it right and how to do this right?
About JWT or Passport - what should I use then?
If you access api directory from client(using angular/react/vue js..) I suggest you to use Passport. in the passport there is a option call Password Grant Tokens, so user have to enter user credential and it'll generate a token(you can adjust the lifetime of the token) and when it expire you can refresh it. And yes if someone stole your token they can access your data
Read this if you want to know more:
https://stackoverflow.com/a/34983109/801448
I'm trying to implement Spring OAuth. I'm new to it and I'm trying to understand how it works.
My Questions:
OAuth generates token after authentication and this token must be used for every request the user makes. We need to append this access_token to each REST API call for accessing the resources. Did I sound correct?
Do we need to store this token on client side (using cookies)? or is there anyway so that we do not need to store this token at client side and can be handled on the server side?
If we have to store the token on client side what's the best way to do it? I have gone through this link
If endpoint on your server is protected by oauth, then yes, you have to pass token with each request - probably in "Authorization: Bearer {token}" header. In spring its solved by using different restTemplate - OAuth2RestTemplate which automatically fetch it and add to request.
You just store just JSESSIONID in a cookie. Then spring read session from store ( disc where tomcat is installed / redis if you use spring session project/ etc )
Access token should be relatively short living. There should also be revoke endpoint available so you can invalidate specific token when there are reasons to believe it was compromised.
3.a) there is another issue with storing some data on client side. Its about storing clientId, clientSecret on mobile native apps. Android apps code can be reverse engineered quite easily, so anyone can then try to use your oauth app to get token. In those situations its recomennded to use different grant type "password" - check https://aaronparecki.com/2012/07/29/2/oauth2-simplified#other-app-types
Very new to okta flow, please bear with my ignorance.
I am doing a poc to access sharepoint from my external site and sharepoint is authenticated through OKTA. I want to start getting list view data from share point and expose it on my site.
1) What is the difference of authenticating using username / password flow (vs) using token to authenticate into OKTA?
Step 1: Auth in through username / password get the session token
Step 2 : After this I tried to create a session as per docs:
http://developer.okta.com/docs/api/resources/sessions.html#create-session-with-session-token
You're probably missing a valid Okta API token (cf. Getting a Token ) when calling the /api/v1/sessions endpoint. In any event, you should use the /api/v1/authn endpoint for authentication purposes and that one usually doesn't need an api token (unless you want to authenticate it from a trusted application).
The /api/v1/sessions API with the username/password payload is deprecated so you should shy away from using it in favor of the /api/v1/authn API.
I hope this helps!
I’m trying to get my head around how I would introduce token-based (key-based?) authentication to a web API (currently looking at Sinatra, but maybe Rails too) that would be used by a mobile client and how OAuth would fit into the picture.
So, let’s say I want to create a web service that uses Facebook for authentication and grabbing basic user data. Here, my API would be a client to Facebook’s OAuth Server, requesting an access token upon a user’s successful login to Facebook. This would then grant me access to the user’s data which I would use to create an entry in my database, storing this user-specific token with any other application information I would like linked to them.
I think I got that part right so far, but here’s where I’m a bit confused.
I think that my API would also need some form of API key to grant access to a mobile user, since I wouldn’t want to transmit and store the Facebook key on their device. Would I have to have a separate store of keys which I provide to the client to access my service? Are there any ‘best practice’ ways of doing this?
Would I have to have a separate store of keys which I provide to the client to access my service?
yes.
Are there any ‘best practice’ ways of doing this?
The simplest way would be to generate a separate authentication token on every User creation and expose that to the mobile client. Then send it with every subsequent request header.
Devise provides a simple example how to achieve that. You don't need devise for that, just provide some token generation mechanism.
#Devise.friendly_token
def self.friendly_token
SecureRandom.urlsafe_base64(15).tr('lIO0', 'sxyz')
end
This mechanism can be extended to provide more security in following ways
Being an oauth2 provider itself.
On successfull login with facebook, you would generate an :authorization_code which the client can exchange for your own Oauth2 Bearer or MAC token within a next step. Then you can send your own Oauth2 token with every request for user authentication.
See rack-oauth2
Implement HMAC token encryption.
Generate and expose a secret_key to every client after singning in. Use this secret to sign messages along with a unique client id. The server can then lookup the secret_key for the specific client_id and verify the message.
See api-auth