We are having troubles with getting the access token from fiware since 4th August.
We are using this URL to ask for the token: https://orion.lab.fiware.org/token but it seems like it does not work.
Before using that URL we used to ask for this one:
http://cloud.lab.fi-ware.org:4730/v2.0/tokens
Could anyone, please, help us?
Thank you in advance.
It depends on how you want to get the token. The current OAuth2 URL to get the tokens is https://account.lab.fiware.org/oauth2/token. This is the central authority for authentication, if you are accessing any common GE, but you will need to register your application in FIWARE Account and use your application credentials and some OAuth2 grant to get it.
If you want to get the token for the global instance without using a registered application, the URL you have mentioned contains a token service that can give you a valid token for your user and that purpose. You can test it (and see an example) with the following script:
https://raw.githubusercontent.com/fgalan/oauth2-example-orion-client/master/token_script.sh
Related
Using the App Console, I am generating an Access Token for use by my java application.
Why is my access token expiring? It worked yesterday but today I get the below error.
How do I get a permanent token for my application to use? (Usage is similar to a "Google Service Account" that generates a permanent token.)
Exception:
InvalidAccessTokenException
{
"error_summary": "expired_access_token/...",
"error": {
".tag": "expired_access_token"
}
}
UPDATE 2022 12 02:
Thanks for the below information and links. After about 5 hours of working on wrapping my brain around the concepts and the example code, I finally got something working by doing the following:
(1) Using the example code and manual process at https://github.com/dropbox/dropbox-sdk-java/blob/main/examples/examples/src/main/java/com/dropbox/core/examples/authorize/ShortLiveTokenAuthorize.java I obtained an auth code.
(2) I then wrote java code to post the auth code to the https://api.dropbox.com/oauth2/token end point and receive tokens including the refresh token.
(3) I then wrote code to post the refresh token to the same end point to receive an access token.
It appears I can hold on to the refresh token and repeat step 3 to get access tokens each time.
HOWEVER, I must be missing something here.
This is WAY too much extra work that should be done either by the App Console and/or the SDK.
Also, it seems to me that a “Client Credentials Flow” should be available in the API and SDK.
Your thoughts?
Dropbox is in the process of switching to only issuing short-lived access tokens (and optional refresh tokens) instead of long-lived access tokens. You can find more information on this migration here.
Apps can still get long-term access by requesting "offline" access though, in which case the app receives a "refresh token" that can be used to retrieve new short-lived access tokens as needed, without further manual user intervention. You can find more information in the OAuth Guide and authorization documentation.
The official Dropbox Java SDK can actually handle the process for you automatically, as long as you supply the necessary credentials, e.g., as shown retrieved in the examples here.
I am creating an application to interact with Tableau's REST API.
I am using Tableaus Online Server to host the workbooks/groups/users etc.
What I need is a way to let a user sign in and then interact with the REST API without having to store a username and password for server authentication.
Currently, if someone wanted to get a list of workbooks, they would need the following code
import tableauserverclient as TSC
tableau_auth = TSC.TableauAuth('USERNAME', 'PASSWORD', site_id='CONTENTURL')
server = TSC.Server('https://SERVER_URL', use_server_version=True)
server.auth.sign_in(tableau_auth)
Tableau does use personal access tokens and I can authenticate like this
import tableauserverclient as TSC
tableau_auth = TSC.PersonalAccessTokenAuth('TOKEN-NAME', 'TOKEN-VALUE', site_id='CONTENTURL')
server = TSC.Server('https://SERVER_URL', use_server_version=True)
server.auth.sign_in(tableau_auth)
The problem I am running into is that signing in with a username and password only returns a token value. I don't think this is meant to be the same as the personal access token, but can I use this token value to authenticate the user and do other actions with the REST API?
The structure of the signin response is
{
credentials: {
site: {id: ...},
user: {id: ...},
token: tokenValue
}
}
You can also create a personal access token manually on the tableau online server. Is there a way to get this value after signing in with a username and password?
Okay, so I kinda figured it out like a few minutes after posting this. And if anyone else gets a little confused when working with the Tableau REST API and their authentication, I hope this helps a little bit.
There is a python package called tableauserverclient and it's supposed to make interacting with the REST API easier. It does, except I don't believe there is a way to pass values to the header of the request. Which is how they manage the access tokens after signing in (and the personal access token is a completely separate thing).
So, when a user signs in, they receive an access token that can be used later to authenticate other services. But, the token needs to be passed in the header as the X-Tableau-Auth value.
So, while the TSC library simplifies and python-izes some of the requests, it doesn't allow you to utilize the access token from sign in.
I'm currently having users login to my site using Auth0's redirect functionality. It's great, but my past experince with google's oAuth tells me there's a problem. With my other site, we do the same login, the user gets a JWT and posts that to my API server. My API server then takes that token and contacts google to ensure this is actually a token that they made. And THEN, I give them a Bearer code that they can use for when they want to access the database.
With Auth0, I can't seem to find any way to contact them from my API server and say, "Hey, someone sent me this token, it checks out that it isn't corrupted, is for a data that is in the future and it says you are the issuer and it has the proper Auth0 client id. So, did you issue this?"
I must be missing something.
Thanks everyone.
I am currently developing financial services as a personal project.
In order to strengthen security in the project, it is designed and implemented to process authentication at the gateway stage using AWS API Gateway.
I tried to log in using a mobile phone number and the received authentication number, and I don't think this is appropriate for Cognito and IAM identifiers, so I'm going to run the Node Auth Server that issues and verifies JWT tokens in AWS Lambda.
In the process, I tried to include an identifier such as user_id or uuid in the payload of the JWT token, but my colleague opposed it.
His opinion was that access token should only engage in authentication and that the token should not contain a user identifier.
I agreed with him to some extent, but if so, I wondered how to deliver the user identifier in an API such as "Comment Registration API".
Should we hand over the user identifier along with the access token to the client when login is successful?
in conclusion
Is it logically incorrect to include the user identifier in Access Token's Payload?
If the answer to the above question is yes, how should I deliver the user identifier when login is successful?
I wanted to hear the majority's opinion, so I posted it.
Thank you.
Typically you want enough information in the access token so that you can also do proper authorization about what the user/caller is allowed to do.
Typically, you separate authentication and authorization like the picture below shows:
So, to make an effective API, you do want to avoid having to lookup additional information to be able to determine if you are allowed to access some piece of data or not. So, I typically include the UserID and some other claims/roles in the token, so that I can smoothly let the user in inside the API.
However, adding personal information in the access token might have some GDPR issues, but sometimes it might be necessary to also add. But I don't see any issues adding information like UserId and roles in the token.
Yes it is logically correct and a normal thing to do. To see how to do it in a Node Auth Server, you can look at this: https://auth0.com/blog/complete-guide-to-nodejs-express-user-authentication/
We would like to implement "Sign-in with LinkedIn" in our app. Since the app has JS fronted and RESt-based backend, we decided to exchange JSAPI tokens for REST API OAuth tokens as described here.
If a user successfully signs in, the frontend sends credentials cookie with client-side bearer token and member ID to the backend. On the backend we check if a user with such a member ID already exists and if not, we exchange JSAPI token for REST API OAuth token, retrieve user details from LinkedIn a store it in our database.
Now the question is if we can use that cookie to authenticate each user's request to our REST backend. After a user successfully signed in via JSAPI, the cookie should be automatically passed to our backend on all subsequent requests so we can check member ID. Are there any drawbacks that we missed? Or is this idea as a whole wrong?
Should we rather authenticate a user only once by means of the cookie and then issue our own authentication token and send it back to the client?
The way cookies work in general is they are passed on every request to the domain they belong to. LinkedIn is setting a credentials cookie to your domain.
As long as you are validating those credentials on every request it's perfectly acceptable to use their tokens as authentication.
Personally I don't find that to be a great idea and would prefer to validate their credentials once and create my own auth token to use from there on out. You can always set that token to expire at some-point and re-validate the LinkedIn credentials (which will still be getting sent on every request anyway). This limits the amount of times you're checking with LinkedIn and should increase the responsiveness of your app.
Either way could work.
If you are using the LinkedIn cookie to validate a user by member id, you should validate the cookie's signature on each request per section 2 of the doc you linked and question 2 of the FAQ.
Using your own token could make it easier to implement an account which belongs to your app and is not necessarily connected to LinkedIn, assuming there's the potential to either connect solely with some other service(s) or no 3rd part(y/ies). Still should validate any time you trust the member id in the cookie though.
The doc provides a validation example in PHP, and if you're interested in improving a ruby version, I have a shameless plug.
The flow that you've outlined in your latest comment of going straight for the OAuth tokens is the best way to go if you were only signing in to convert the JSAPI tokens to OAuth tokens and then not using the JSAPI further. If you were planning to actually use both the JSAPI tokens within your front-end app and the OAuth tokens on your back-end, then it's better to take the conversion route.