Identity and Data Security for Web Development

Errata for Identity and Data Security for Web Development

Submit your own errata for this product.

The errata list is a list of errors and their corrections that were found after the product was released.

The following errata were submitted by our customers and have not yet been approved or disproved by the author or editor. They solely represent the opinion of the customer.

Color Key: Serious technical mistake Minor technical mistake Language or formatting error Typo Question Note Update

Version Location Description Submitted by Date submitted

There is a typo in "STEP 1A: GENERATING KEYS WITHOUT FILE STORAGE" paragraph. The phragment says:
There is a popular package, named ursa, for doing just that, and we install it like so:

npm install fs --save

The error is in npm statement, must be:
npm install ursa --save

Dima Milyh  Jan 01, 2018 
Printed Page 70
1st paragraph

In the 1st paragraph (Access Tokens) there is a statement that says:
" Using the Access Token to access resources consumes the token.".

This statement does not appear to be true.
In OAuth 2.0, RFC 6749, it says on p 11: section 1.5 Refresh Token;
in the description of the steps shown in fig 2. steps c,d,e:

"(C) The client makes a protected resource request to the resource server
by presenting the access token.

(D) The resource server validates the access token,
and if valid,serves the request.

(E) Steps (C) and (D) repeat until the access token expires.
If the client knows the access token expired, it skips to step (G);
otherwise, it makes another protected resource request."

The key point is that "Steps (C) and (D) REPEAT until the access token expires."

i.e the statement in the book that says what's quoted above is wrong.

The statement should be removed and replaced by a statement indicating that the Access Token may be used REPEATEDLY until it expires.

In addition, the statement in the 2nd para p 11, section: "Refresh Tokens", is also wrong:
"Refresh Tokens allow refreshing Access Tokens
after they are consumed or expired."

i.e. there is no need or statement in 6749 indicating that an access token needs to be refreshed after it is "consumed". In fact, the word, "consume" does not even appear in 6749. Maybe this is an OAuth 1.0 artifact? I do not have time to investigate the obsolete OAuth 1.0 spec.

Please don't tell me I am confusing Access Tokens and Refresh Tokens. I am not.

Rich Levinson

Rich Levinson  Mar 27, 2017 
PDF Page 76
RefreshTokenModel code sample, line 7 (counting empty lines)

Line 7 is:

token: { type: String, default: uuid.v4() },

The issue is the default value: It's assigned the result of calling the uuid.v4() method, which means all new generated tokens will have the same access token value, which is a security issue in the design.

The line should be:

token: { type: String, default: uuid.v4 },

Stefan Cameron  Feb 01, 2017 
Printed Page 76, 87
p 76:top: code lines 1 and 4; p 87:bottom: code lines: 5 and 7

I am rating this serious, because it is a major pain to encounter things like this w/o any explanation.

On p 76, there are 2 elements in the Token Schema in the section purportedly intended to educate the reader on "Handling a Token's Lifetime", which begins on bottom of p75.

line 1: " expiresIn: { type String, default: '10800' } "

line 4: " createdAt: {type Date, default:, expires: '3m'} "

Following this code, there is a statement that says:
"You will notice that an expires flag has been defined.
It’s set to 3 minutes and will cause the database entry to be deleted"

The above comment is referring to line 4. However, in line 1, there is a default value for "expiresIn" of 10800 seconds or 3 hours. As defined on p70, "expires_in" is the "lifetime in seconds".

So, ok, maybe line 4 should say '3h', or maybe, line 1 should say '180' seconds, which is 3 minutes.

However, the same type of problem also comes up on p 87:, at the bottom of the page where code line 5 (not counting blank lines) says:

line 5: " createdAt {type Date, default:, expires '1m' } "

line 7: " exp { type: String, default: Math.floor(new Date() / 1000) + 180 } "

So, in this case we have the ID Token exp set to expire 3 minutes (180 s),
after the issue time (iat),
but we have the "expires" value of 1 minute in the createdAt field, which was defined above as when the token will be deleted from the db.

Aside from the fact that either 1m or 3m seems like an unusually short lifetime for an ID Token, which is used for logging in to an appl, there is the question of why there are 2 values at all: 1m or 3m? i.e. why set a value in the ID Token the says it will be good for 3 minutes, while at the same time ensuring that it will expire in 1 minute?

Either this is wrong, or it requires some sort of explanation.

Again, the reason this is "serious" is that for a reader, such as myself, trying to learn from this book, I am finding, that either errors or typos, all having to do w the same subject, or possibly simply missing explanatory text, renders the whole subject completely unintelligible, unless, of course, I already knew the answers and wouldn't be reading the book in the first place.

Rich Levinson

Rich Levinson  Mar 27, 2017 
PDF Page 87
IdTokenModel code sample, lines 7-9 (counting empty lines)

Lines 7-9 are:

iat: { type: String, default: Math.floor(new Date() / 1000) },
exp: { type: String, default: Math.floor(new Date() / 1000) + 180 },
sub: { type: String, default: uuid.v4(), maxlength: 255 },

In each case, the default value should be a function, not a static value. As it is, all ID tokens will have the same issue time (iat), expiration time (exp) and subject identifier (sub). This would pose a security issue in the design.

The lines should be:

iat: { type: String, default: () => Math.floor(new Date() / 1000) },
exp: { type: String, default: () => Math.floor(new Date() / 1000) + 180 },
sub: { type: String, default: uuid.v4, maxlength: 255 },

Stefan Cameron  Jan 31, 2017