Solana Error: Warning! Token names and logos are not unique. This token may have spoofed its name and logo to look like another token - web3js

I minted token with my web3js script and received such warning in Solana explorer:
Warning! Token names and logos are not unique. This token may have spoofed its name and logo to look like another token. Verify the token's mint address to ensure it is correct.
https://explorer.solana.com/address/DgpDPmAHE7bpgjEG8TksyqiKszoLAFWrrKa3MzNW8d3n?cluster=devnet
Token names and logos are unique:
https://gateway.pinata.cloud/ipfs/QmdL6fLjXTp7xRtXCKP9MdyyJhvQGm5emphCnmRe57AGNB
What is wrong with this token?
Thanks for any help.

You can check the Solana Explorer source code to see what triggers this warning https://github.com/solana-labs/solana/blob/master/explorer/src/pages/AccountDetailsPage.tsx#L210=
Tokens are considered verified only if part of the spl-token-registry. However, this repository has recently been deprecated in favour of Metaplex token metadata standard.

Related

JavaBearer Token validation in Azure AD

I'm trying to validate a token (just using postman), final solution would be written in Java (spring). The problem is I don't find the exact URL to validate the token against AAD.
I found this helpful article : https://learn.microsoft.com/en-us/answers/questions/884100/azure-ad-access-token-validation.html
And in that article they said to validate the token against this URL: https://login.microsoftonline.com/<<<tenant_id>>>/v2.0/
The problem is I got 404 when I hit that URL.
I also got "200 OK status" when I hit this URL https://login.microsoftonline.com/<<<tenant_id>>/oauth2/v2.0/authorize no matter what I put in the token !! Which is strange!
This link works for me: https://login.microsoftonline.com/<<<tenant_id>>/discovery/v2.0/keys - and I get back a very descriptive JSON, but I am still stuck.
Could you please provide me the URL which would give me 200-ok when I have a valid token, and also to give me a bad-invalid response when I have a wrong token ?
I found some sample Postman requests here: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth-ropc?WT.mc_id=AZ-MVP-5003203
I got same behavior with them.
Thank you.
There is no introspection endpoint listed in https://login.microsoftonline.com/common/.well-known/openid-configuration
This authorization-server obviously supports JWTs only. To validate access-tokens, you'll have to configure a JWT decoder/validator in your Java app.
With Spring, this is done by configuring a JWT resource-server. Sample in this article. Skip the part about Keycloak and use
spring.security.oauth2.resourceserver.jwt.issuer-uri=https://login.microsoftonline.com/common in properties
not sure this authorization-server provides with user roles or groups or whatever claim to map spring authorities from (try to submit an access-token to https://jwt.io to see if you have a claim like that)

Amazon SP API getting internal server error

I am trying to get access token from api https://api.amazon.com/auth/o2/token
POST /auth/o2/token HTTP/l.l
Host: api.amazon.com
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
grant_type=refresh_token
&refresh_token=Aztr|...
&client_id=foodev
&client_secret=Y76SDl2F
But after POST request I get 500 server error.
Is it because my app is in draft status? or I am missing something while making request?
If it because of draft status then when the status will get change? any thoughts on this.
Thank you for your help in advance.
The documentation is wrong. I was getting the same exact error and came across this comment on a github issue which mentioned that the data has to be passed into the body of the request, not as query string parameters. Sure enough, this worked for me and I was able to get an access token. So just to clarify: grant_type, refresh_token, client_id, and client_secret should be passed into the body of the POST request to https://api.amazon.com/auth/o2/token and NOT as query string parameters.
Draft status will not keep you from requesting and receiving the access token.
Here are a few things to check as not much can be derived from the example post request from the documentation:
Did you configure AWS IAM role / policy / user properly
Did you use the correct IAM ARN when registering the application
Are you using the correct LWA credentials (I am assuming you're not passing foodev and Y76SDl2F as those are example parameters)
Have you self authorized the application (are you using the refresh token generated
for the authorized application)
Are you 'assuming the role' before the token exchange -- this is a very important step
and is very different in comparison to how access was handled with MWS -- if
you have not, the server will reject the token exchange regardless if the refresh
token is correct. More on that here
This is a non-exhaustive list, just some common issues I have seen other developers have with getting the access token during development, if these don't work you'll need to work with support as they can see the requests hitting the token endpoint.

Invitations API returns 401 Access token validation failure. Invalid audience

I have an MSDN subscription linked to my Personal account. I am trying to write and Web Application which can invite users users using the Invitation API, https://graph.microsoft.com/v1.0/invitations.
I tried to get an token using the Client Credentials flow and then call the above API but getting an invalid audience error. I checked the token and the aud claim is set to 00000002-0000-0000-c000-000000000000 which i think is Graph API. I set the Scope as https://graph.microsoft.com/.default while getting the token
Can some one help me what is that i am doing wrongly or is this scenario not supported
Since you are trying with your personal account which is not supported at this moment as you could see on screenshot below:
You could have a look on official document here
I have tried below way and worked for me:
Request:
{
"invitedUserEmailAddress": "kironTest#email.com",
"inviteRedirectUrl": "https://myapp.com",
"userType":"Guest"
}
Response:
Make sure your token has required permission like below:
You could check your permission here https://jwt.io/
Hope that would help.

Do we really need id_token in implicit flow in OIDC?

I'm working on a SPA application, and I'm using the recommended implicit flow and I'm able to get access_token and id_token. As I need more than the profile info, I've created a separate endpoint to return the user profile information (along with all the other information that's specific to our business) and this endpoint is protected, and can be accessed only with an access_token as the bearer token. Right after getting access_token in SPA, I call this endpoint to get all the user information (which includes first name, last name etc., that gets displayed on the UI). If there is any problem with the returned id_token and access_token pair, the user profile info endpoint call would fail. So, do I really need to validate the id_token? as I'm not relying on any information within that token.
For authenticating against external login provider or authorization code flow, validating the id_token makes sense, but in my case I'm not sure about it.
According to OpenID spec:
When using the Implicit Flow, the contents of the ID Token MUST be validated in the same manner as for the Authorization Code Flow, as defined in Section 3.1.3.7, with the exception of the differences specified in this section.
1. The Client MUST validate the signature of the ID Token according to JWS [JWS] using the algorithm specified in the alg Header Parameter of the JOSE Header.
2. The value of the nonce Claim MUST be checked to verify that it is the same value as the one that was sent in the Authentication Request. The Client SHOULD check the nonce value for replay attacks. The precise method for detecting replay attacks is Client specific.
Why don't you utilise response_type parameter in authorisation request. By changing its value, you can alter what you receive for authorisation response.
Identity documentation mention about possible response type values. Following is an extraction from their documentation,
As you can see, if you do not want SPA to receive the id token, you can set the response_type value to token. If you do so you will only get an access token, which is enforced by OAuth 2.0 specification. (See the OAuth 2.0's implicit flow response_type explanation from here). Note that when you use response_type=token , you are using OAuth 2.0 (not OIDC)
I don't see any wrong in your approach as long as you utilise features enabled by respective protocols.

How should a JavaScript application validate an access_token issued by IdentityServer4?

For example, suppose I want to determine if a user is still "logged in"... AKA their token is not yet expired.
I store my JWT access_token in localStorage when I am first issued the access_token. I know it isn't enough to simply check the localStorage to see if the access_token is there or not. I read about the introspection end point but that seems like it is for API's - not JS clients. Is the best approach to use a client side library for JWT validation? I don't like this because there is a chance I may need to switch to reference tokens. I would like to make a call to the server side for this.
What is the correct way to validate an access_token with a JavaScript client?
Update:
Upon further investigation and with advice from leastprivilege I will be using the OIDC JavaScript client so I don't need to worry about this.
Client applications are not supposed to "decode" an access token. The exact format is an implementation detail between issuer and API.
When requesting an access token, the token response contains an 'expires_in' parameter that tell the client for how many seconds the token is valid.
Most jwt tokens come with an expiry date field for expiration time(depending on the server though). You can use a library like this to decode a JWT token before saving it into your local storage and then save the expiration time inside with the token so that you can just check the local storage and the expiry time and if the current day is grater than the expiry time, you discard the previous token and get a new one.
This library might be useful to you: oidc-client-js. Some documentation is available here.

Resources