To summarize, we have decided so far that
1) we can have a token table to store and lookup tokens that we issue OR we can generate tokens where the tokens bear user, client, time of issue and bearer status.
2) we can use encryption and decryption effectively to generate tokens. We could keep the encryption or decryption logic in the database.
3) Tokens that we generate will be tamperproof, cannot be faked and will have all the security information required to handle the requests.
4) Tokens can have fixed length strings for user, client, time of issue and bearer status, preferably integers
5) On decryption, the client Id in the token will be validated against the apikey of the caller to ensure that the caller is the authorized one.
6) The protected resources of the client should match the user information from the token.
7) These security validations happen as filters to the API calls so that the calls themselves don't have to implement any validation logic.
8) Audit trail of all token grants and calls can be made by intercepting traffic on the server side. URI logging may not work since bearer tokens may be passed in the request body.
9) Tokens are expected to be short lived such as for an hour so clients are forced to request again.
10) Token granting and validations should be performance. Choice of technology should not degrade performance. In the bigger picture, the overall cost of token validation should not exceed one tenth the time taken in network delays and hops to reach the authorization server.
11) User and client information from token is independent from the userId and clientId in the API resource qualifier. The APIs could choose to shorten it
12) token expiration could be validated as well
13) token with bearer flag will skip client validation
14) token should include some kind of magic number from authorization server
15) Client registration could be handled as part of webUI.
16) Client registration information could keep track of redirect uri
17) Authorization code could be distinguished from the token by a flag.
18) Code to token translation can be permitted if code is validated just the same way as tokens were decrypted and validated
19) Token granting can be based on any workflow but the token itself does not need to have any of the information about the grant type. Special userId and clientId will be required for cases when userId is missing or the token is permitted by different client types.
20) Tokens once issued is generally not expected to be issued again.
21) By tokens we are referring to the access_token parameter in the above and its length should preferably be within 50.
22) New workflows could be created or existing workflows can be used for generating or using the same token.
1) we can have a token table to store and lookup tokens that we issue OR we can generate tokens where the tokens bear user, client, time of issue and bearer status.
2) we can use encryption and decryption effectively to generate tokens. We could keep the encryption or decryption logic in the database.
3) Tokens that we generate will be tamperproof, cannot be faked and will have all the security information required to handle the requests.
4) Tokens can have fixed length strings for user, client, time of issue and bearer status, preferably integers
5) On decryption, the client Id in the token will be validated against the apikey of the caller to ensure that the caller is the authorized one.
6) The protected resources of the client should match the user information from the token.
7) These security validations happen as filters to the API calls so that the calls themselves don't have to implement any validation logic.
8) Audit trail of all token grants and calls can be made by intercepting traffic on the server side. URI logging may not work since bearer tokens may be passed in the request body.
9) Tokens are expected to be short lived such as for an hour so clients are forced to request again.
10) Token granting and validations should be performance. Choice of technology should not degrade performance. In the bigger picture, the overall cost of token validation should not exceed one tenth the time taken in network delays and hops to reach the authorization server.
11) User and client information from token is independent from the userId and clientId in the API resource qualifier. The APIs could choose to shorten it
12) token expiration could be validated as well
13) token with bearer flag will skip client validation
14) token should include some kind of magic number from authorization server
15) Client registration could be handled as part of webUI.
16) Client registration information could keep track of redirect uri
17) Authorization code could be distinguished from the token by a flag.
18) Code to token translation can be permitted if code is validated just the same way as tokens were decrypted and validated
19) Token granting can be based on any workflow but the token itself does not need to have any of the information about the grant type. Special userId and clientId will be required for cases when userId is missing or the token is permitted by different client types.
20) Tokens once issued is generally not expected to be issued again.
21) By tokens we are referring to the access_token parameter in the above and its length should preferably be within 50.
22) New workflows could be created or existing workflows can be used for generating or using the same token.
No comments:
Post a Comment