We are using STS token for claims based identity.
I found that following method validates the token from STS and generates claims.
FederatedAuthentication.ServiceConfiguration.SecurityTokenHandlers.ValidateToken(token)
1.Does this method validate the token against the schema provided by OASIS?
2.If so how does it know which schema it has to validate against? becasue there are multiple schemas (like 1.1, 1.2).
Or Am I asking wrong question.. Do we need not validate the token against schema?
Thanks in adavance
You should assume that, if the Token is XML, the TokenHandler will validate the XML. It has to do that anyway to avoid signature insertion attacks. If you are in doubt because you have prove that it actually allows invalid XML through, then you should report a bug.
The first element of the assertion has an attribute that indicates the version of the protocol/XML-schema
Related
I am making an application that generates refresh token that implements JWT token authentication, and I am not sure what format should I use to identify the refresh token. Initially, I thought that it should be in JWT token format, but based on my googling, it seems like it is represented in a UUID or hashed format? Just wondering whether I should make it JWT token format, or it does not matter in the case of refresh token?
Thanks in advance for helping to clarify this issue.
From here https://developer.okta.com/docs/guides/refresh-tokens/main/ refresh token response it shows the refresh token format is not in JWT format.
First decide how you want to model this, which might work like this:
User authenticates (and optionally consents)
Create a delegation to represent the user action
Delegation is stored as a database row
Fields include sub, client_id, refresh_token_hash, scopes_issued, claims_issued, issuance time, expiry time
Subsequent token requests are validated against the persisted state
The hash might be the returned to clients, or they may be given a different identifier. It is a pointer to backend state.
You might also need to implement support for refresh token rotation, revocation, auditing of tokens issued and so on. Consider using an authorization server, as described in RFC6749, to handle this stuff for you.
I didn't make such decisions with implicit flow (I know it's not so good to use it), but I currently have situation where I have to validate my access token on backend(Java 8). Is it okay for every request with access token additionally call oidc provider to check if token is active(not revoked, with valid lifetime) or there is more appropriate way how to handle it? Anyway thanks
I am using IdentityServer4 Implicit flow for my Angular application. I have permissions claim added to scope list and also it gets populated properly.
i need to update this claim value whenever i change the value in database.
currently, the claim value is refreshed only when access_token is refreshed/renewed.
I want to check/update claims on every call to api.
Two things:
You are mixing authentication with authorization. The permission claims should not be present in the Access token. Please read here why. And read my answer here for some thoughts about a possible design.
You can't change a JWT.
An access token contains information about the client and the user (if
present). It is a self-contained code that can be decoded by the
server only and has a certain lifetime.
Please note that the refresh token does not really refresh the access token, it creates a new token. The original token remains valid until it expires. An alternative is to use Reference Tokens.
sorry if this is question is too broad, but I have to ask this since I'm learning web development and I feel if don't ask I won't know.
So, I'm doing authentication using oauth2, and right now I'm already at point where I successfully authenticate user, and now I'm receiving what they call tokens. The question is, how do you use token to authenticate user to your own server?
I'm thinking something like creating a cookie that maps to a token, so when user acts, each time I'll get a cookie and I know that this is user A. Is method like this safe or not? If not, in what way people usually use the token? Although this is only a hobby project, I'd like to be "as real as possible". Any thoughts?
As per my knowledge Oauth2.0 provides InMemoryTokenStore and JdbcTokenStore for persisting tokens. When a request comes from an authenticated user Oauth2.0 will check if it has a valid token already. In case it doesn't it will create one.
Basically usage of tokens depends on the grant-type you are using . Following are the two commonly used grant types -
1) Implicit - The token is send back in the url as a parameter and is included in the subsequent request* in the parameter.
2) Authorization Code - In this case the token is generated and set in the header of the request*.
*the request here is the one which is finally sent to resource server for accessing protected resources.
I think you dont need to create a cookie for storing tokens. In case you are using Authoziation Code grant type which is the default, Oauth2.0 will use session for storing state and code which will be used for retrieving token.
I save tokens obtained through authorization and use them for post and similar requests. However I need to know when to re-login in case of token expiration.
Does scribe throw any relative exception ? Judging by the sources it doesn't but maybe it throws any other ? Maybe you can suggest a better way ?
Scribe can't tell if a token is expired or not. There's no standard way in OAuth for the provider to inform you that a token was valid and now it isn't.
It's kind of logical that it works that way, tokens have a life span and after that they become rubbish. There's no way of differentiating between a just-expired token and a random string.
The only way you can check is (surprise!) making a request and seeing if it works. Your client can keep some kind of state to check wether the request is getting an unauthorized response with a previously valid token and in that case try to reauthenticate but, sadly, there's no way the provider (or scribe for that matter) can make that easier for you. Sorry.