I am unable to get token for my api using the set up as shown in the image. As you can see the hashed value does not have a '+'. The unhashed password is 'ecret'. That is not a typo. I have also tried RequirePkce to false. I have turned on logging for identity server but it has only limited information. There is a single message.
Client secret validation failed for client:api.client.
I have also seen SO entry here.
Finally I was able to figure out. The samples are behind the development. Documentation may be little more updated.
While searching for other authorization mechanisms, it occurred to me that HTTP had an authorization header as in the image.
Related
I'm trying to verify subscription purchase in our backend servers, considering from this hms-iap-serverdemo GitHub repo.
I'm trying to connect OAuth 2.0-based authentication servers using app ID and app secret. I took ID and secret from AppGallery Connect → my app → app information. The auth servers returns base64 encoded token. When I try to verify with this subscription purchase, I am getting ResponseCode:6 ResponseMessage:Token is expired or invalid InappPurchaseData error from server.
The status of the application is currently draft. Is that why I'm getting this error? I believe client ID and client secret is correct. Or something else. I do not know. Do you have an idea?
Thank you
ResponseCode:6 ResponseMessage:Token is expired or invalid InappPurchaseData
The possible causes are as follows:
Check whether the token is invalid.The token validity period is 1 hour. If the token expires, obtain a new token to ensure that the token is valid.
Check whether the AT is invalid and whether only the AT in the cache is obtained. If the AT is invalid, clear the cache and obtain the AT again. Generally, use the token interface to obtain the application-level AT again.
For details about how to obtain the application level AT, see docs.
The token format is incorrect.
According to the docs:
App-level access token: Authorization: Basic Base64(APPAT:atvalue)
Example: The app-level access token is thisIsAppAtValue, then APPAT:atvalue is APPAT:thisIsAppAtValue.
Therefore, replace APPAT:atvalue in Base64(APPAT:atvalue) with "APPAT:thisIsAppAtValue" to generate value QVBQQVQ6dGhpc0lzQXBwQXRWYWx1ZQ==.
The value of Authorization in the request header is as follows: Basic QVBQQVQ6dGhpc0lzQXBwQXRWYWx1ZQ==
The site request is incorrect.
Switch to a proper site based on your location and try again.
China: https://subscr-drcn.iap.hicloud.com
Germany: https://subscr-dre.iap.hicloud.com
Singapore: https://subscr-dra.iap.hicloud.com
Russia: https://subscr-drru.iap.hicloud.com
I have been trying to perform a token based authentication (TBA) with netsuite, but keep getting "Invalid Login Attempt"
I tried to refer to this also:
How to request Netsuite RESTlet with TBA authentification
And I tried it both on
python:
https://gist.github.com/axilaris/6ecc58e43895dba17ce0ca1b8ce25d9a
(please check the code and response error)
it was mainly based on https://www.techfino.com/hubfs/Techfino_March2018/Images/Token-Based-Authentication-Guide-for-NetSuite.pdf
and
postman:
Here are my netsuite configuration for the permissions:
"Invalid login attempt" is a generic error thrown by NetSuite when there's something misconfigured in the authentication headers. The best way to troubleshoot this is to use the "Login Audit Trail" search. From there, you should be able to troubleshoot what went wrong with your parameters. It could be that you entered an extra character or blank space into one of your tokens or you’re not generating a new timestamp or nonce.
Follow these steps:
Go to Setup > Users/Roles > User Management > View Login Audit Trail.
Check the Use Advanced Search box.
Click the Results subtab.
Add the following fields: Detail, Token-based Access Token Name, and Token-based Application Name.
Application Name.
Click Submit.
The Detail column displays error messages for any token-based authentication logins with a status of Failure.
After carefully debugging I found out that timestamps for generating request token are taking more time. I changed the time offset with my standard time zone. After syncing time, it worked for me. So even token definitions in NetSuite don't expire, timestamps for generating request tokens must be in time-window with time in the NetSuite environment.
Also Check these points:
Doesn't have the Web Services Only Role checked.
Check that your related integration has the TOKEN-BASED AUTHENTICATION checked.
Try switching from HMAC-SHA1 to HMAC-SHA256 for your signature method. NetSuite is ending support for SHA1 and I already had an issue with it once.
I am using OKTA.
Looks like that i got an error when clicking on login button:
OAuthError: Could not acquire access token from authorization code.
My app is in LIVE. All the settings in app dashboard look correct, because I took a simple js sdk in index.html file and made it work. So Something happens on okta Size. I am using social/identity providers.
Anyone has ever used okta and reached this error?
Another hint is that their support somehow on their back-end admin panel checked and they also get another error message: "Cannot call API on behalf of this user"
I had the same issue, in my case the issue was because the security secret key didn't match with the one in the IDP database.
If you have generated manually the secrete key check that the key is created using ssh256 hash.
You can find how to generate a secrete key here
https://stackoverflow.com/a/44013730/4878365
The server side verification is failing for me with code 32 and message "Could not authenticate you.". I have an android app where i am using digits to authenticate users using their mobile number. Inside the success callback, i follow the oauth echo tutorial and use the consumer key and secret along with auth token and secret obtained from digit session to generate an oauth signature(X-Verify-Credentials-Authorization) as well get the url to hit to verify credentials(X-Auth-Service-Provider) on the backend. I then try to do a curl request by plugging the oauth signature into Authorization header for the request as indicated in the tutorial. However i get error code 32 - could not authenticate you. Have tried with multiple numbers without any success. It would be great if anyone could indicate what i am doing wrong or provide any help in fixing this. Without this fix, i am afraid i would have to use my exisiting OTP architecture and won't be able to take advantage of this fantastic library.
I'm building a picture diary on web application google app engine using python. Users can sign up and post pictures to their diary.
Also, I'm trying to conform as much as I can to the REST architecture of doing things.
The authentication scheme is based like this for the web application:
1. Post username/password from the frontend
2. Backend sets up a cookie if authentication is successful
3. The rest of the AJAX calls made are authenticated using this cookie.
Is there any way to conform to REST without using cookies ?
Now, I'm also building an android application where users can sign in and post/view their picture diary. I need to expose the data from web application's datastore so I'll be building a webservice to fetch data from the datastore.
The authentication scheme for the android client:
OPTION a
1. Post username/password over https to the web service
2. Web service returns a unique authorization token (store the token in the username/pwd table on the datastore)
3. Request subsequent services by adding this token to the Request Header of the request
4. Server maps the token to the username/pwd table and returns data if token is found
5. Authorization token expires after a certain period of time
OPTION b
1. Set up a secret key on the client and server side
2. Use "username:hash of password and secret key" in the authorization header of every request
3. server generates the password by extracting the password from the hash value using the same hash algorithm ; if successful returns data
btw, I didn't wanna use basic authorization because of its security vulnerabilities.
Which is better ?
Are there other significantly better ways to accomplish what I'm trying to do ? Security is quite a concern for me btw.
I'd appreciate if anyone has any insight into this issue. thanks.
I've been doing some research myself as to what would be the best solution. I think the 2-legged oauth might work in my case as Leonm suggested.
In this case the server has to provide the client with a consumer key/secret which in my case is hardcoded in the app.
The steps now would be:
1. Generate a signature using the oauth_parameters(consumer_key, signature_method, timestamp), request url, request parameters, and the SECRET.
2. Include the signature, oauth parameters when making a request.
3. Server verifies the request by generating the signature again except in this case it uses the SECRET that corresponds to the key
I think this way I am pretty much confirming to the REST principles. The server is statless as I far I understand now.
What are the pros/cons on doing things this way?
If "security is a concern" then I would say that you'd be a lot better off using open standards and a library to achieve what you want. The main reason for this is that if you do it yourself, you're very likely to forget something; these standards have had a lot of eyes looking at them, looking for holes.
Your options include (in increasing level of complexity)
Basic authentication and HTTPS
Everything is encrypted, which makes it impossible to compress or look into, it increases the overhead somewhat, using more horsepower on the server, and more perhaps battery power on the client. Simple to implement, since it's well supported by libraries.
Digest authentication
Unencrypted messages pass the wire, but the authentication is securely managed in the Authorization headers. See the wikipedia entry for more information.
OAuth
See how Google is providing OAuth for installed applications. I believe it isn't what you're looking for, since you're not asking to share data between applications, just authenticating users.
Roll your own
If you want to roll your own, I suggest looking at e.g. how Google's (now deprecated ?) ClientLogin used to work.
Clients would GET a protected resource, and get a 401 with instructions to perform a GoogleLogin authentication, including a URI for where to perform the login itself
Clients (knowing how to do this) POST a request in a specific manner to that URI
The server responds with a specific response including a (long) token
The client can now perform GET requests to the protected resource with that token.
Statelessness
You cite REST, which dictates that requests should not specifically depend on prior interaction: "... each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server." (fielding) This means that a server shouldn't store conversational context (like an authentication token) in a table.
One way of fixing this is by using any of the token based approaches (where the server tells the client about a token it should use for future requests) where the token is not a random number, but a message to the server itself. To protect yourself from client tampering, it can be signed, and if you're afraid of clients looking at it, you can encrypt it.
Edit: Although I'm not certain, it seems unlikely that Google has a table of all authentication tokens ever issued; The length of their tokens suggests that the token is some encrypted message proving that whoever holds this token actually provided real credentials in some realm at some time.
OAuth does exactly what you want to do in a standard way.
You could use a combination of HTTPS and HTTP Basic Auth. Both are existing standards and should be secure enough when used together.